Woran erkennt man einen guten SQL-Entwickler anhand seiner Arbeit?
Beispiele hierfür könnten sein:
Verwendet selten CURSORs und versucht, sie durch Refactoring zu entfernen.
Verwendet selten temporäre Tabellen und versucht, sie durch Refactoring zu beseitigen.
Behandelt NULL-Werte in OUTER JOINs mit Sicherheit.
Vermeidet SQL-Erweiterungen, die nicht häufig implementiert werden. Er weiß, wie man elegant einrückt.
Ich habe die Erfahrung gemacht, dass ein hervorragender SQL-Entwickler in der Regel auch ein hervorragender Datenbankdesigner ist und es vorzieht, sowohl am Design als auch an der Implementierung der Datenbank beteiligt zu sein. Das liegt daran, dass ein schlechtes Datenbankdesign selbst den besten Entwickler frustrieren und zurückhalten kann - gute SQL-Instinkte funktionieren nicht immer richtig angesichts pathologischer Designs oder Systemen, bei denen RI schlecht oder gar nicht vorhanden ist. Eine Möglichkeit, einen guten SQL-Entwickler zu erkennen, besteht also darin, ihn bei der Datenmodellierung zu testen.
Außerdem muss ein großartiger DB-Entwickler die komplexe Verknüpfungslogik beherrschen und genau wissen, wie die Ergebnisse verschiedener Multiway-Joins in unterschiedlichen Situationen aussehen werden. Mangelnde Vertrautheit mit Joins ist die Ursache Nr. 1 für schlechten SQL-Code (und schlechtes SQL-Design, um genau zu sein).
Was die spezifische Syntax angeht, so würde ich bei Direktiven wie:
Verwendet keine CURSORs.
Verwendet keine temporären Tabellen.
Anhand dieser Techniken können Sie den Unterschied zwischen einem gefährlichen Amateur-SQL-Programmierer (der sie verwendet, obwohl einfache relationale Prädikate weitaus besser wären) und einem guten SQL-Anfänger (der das meiste ohne sie erledigen kann) erkennen. In der Praxis gibt es jedoch viele Situationen, in denen Ausweichtabellen und Cursors völlig ausreichend (manchmal sogar die einzige Möglichkeit) sind, um etwas zu erreichen (abgesehen davon, dass man die Verarbeitung auf eine andere Ebene verlagert, was manchmal ohnehin besser ist).
Die Verwendung dieser fortgeschrittenen Konzepte ist also nicht verboten, aber wenn Sie es nicht gerade mit einem SQL-Experten zu tun haben, der an einem wirklich schwierigen Problem arbeitet, das sich aus irgendeinem Grund nicht für eine relationale Lösung eignet ... ja, dann sind das wahrscheinlich Warnzeichen.
Ich glaube nicht, dass Cursors, temporäre Tabellen oder andere SQL-Praktiken von Natur aus schlecht sind oder dass ihre Verwendung ein klares Zeichen dafür ist, wie gut ein Datenbankprogrammierer ist.
Ich denke, dass es für jede Art von Problem das richtige Werkzeug gibt. Klar, wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus. Ich denke, ein guter SQL-Programmierer oder Datenbankentwickler ist jemand, der weiß, welches Werkzeug in einer bestimmten Situation das richtige ist. IMHO kann man nicht verallgemeinern, ohne bestimmte Muster auszuschließen.
Aber als Faustregel kann man sagen: Ein guter Datenbankentwickler findet eine bessere kurze und elegante Lösung für komplexe Situationen als der durchschnittliche Programmierer.
Hier sind ein paar Dinge, die nicht für gewöhnliche Softwareentwickler gelten, aber für jemanden mit guten SQL-Kenntnissen:
Die Beispiele, die Sie anführen, wie die Nichtverwendung von Cursoren, temporären Tabellen oder die Kenntnis von 3 alternativen Abfragen für eine bestimmte Aufgabe, würde ich no Anzeichen dafür, dass Sie ein guter SQL-Entwickler sind. Vielleicht würde ich jemanden, der diese Dinge tut, als einen " Akrobat ."
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
