Kann jemand Codierungsstandards für TSQL empfehlen?

Wir haben seit langem Codierungsstandards für unseren .Net-Code, und es scheint mehrere seriöse Quellen für Ideen zu geben, wie diese angewendet werden können, die sich im Laufe der Zeit weiterentwickeln.

Ich möchte in der Lage sein, einige Standards für SQL zusammenzustellen, die für die Verwendung durch unsere Produkte geschrieben wurden, aber es scheint keine Ressourcen für den Konsens darüber zu geben, was gut geschriebenes SQL bestimmt.

Nach meiner Erfahrung wären die wichtigsten Dinge, nach denen ich suchen würde:

• Tabellen- und Spaltenbenennung - Überprüfen Sie, ob Sie ID, Referenz oder Nummer für Spalten vom Typ ID, Singular oder Plural für Namen verwenden (Plural ist für Tabellennamen üblich - z. B. THINGS, Singular für Spaltennamen - z. B. THING_ID). Für mich ist das Wichtigste hier die Konsistenz, die verhindert, dass Menschen Zeit verschwenden (zum Beispiel stoßen Sie nicht auf Tippfehler, bei denen jemand THING als Tabellennamen eingegeben hat, weil Sie nur intuitiv wissen, dass Tabellennamen niemals singulär sind).

• Alle Erstellungen sollten einen Drop (abhängig vom vorhandenen Objekt) als Teil ihrer Datei enthalten. Möglicherweise möchten Sie auch die Berechtigung zum Erteilen von Berechtigungen bis zu Ihnen hinzufügen.

• Auswählen, Aktualisieren, Einfügen und Löschen sollten einen Spaltennamen, einen Tabellennamen und eine where-Klausel / Reihenfolge nach Klausel pro Zeile enthalten, damit sie während des Debuggens einzeln leicht auskommentiert werden können.

• Präfix für Objekttypen, insbesondere dort, wo sie verwirrt sein könnten (daher ist v für die Ansicht am wichtigsten). Ich bin mir nicht sicher, ob es noch zutrifft, aber es war früher ineffizient, wenn andere gespeicherte Prozeduren als Systemprozeduren mit sp_ beginnen. Wahrscheinlich die beste Vorgehensweise, um sie trotzdem zu unterscheiden. Usp_ war das, was ich zuletzt verwendet habe.

• Ein Standard, der angibt, wie der Name eines Triggers enthalten soll, ob er aktualisiert / eingefügt / gelöscht werden soll, und für welche Tabelle er gilt. Ich habe keinen bevorzugten Standard, aber dies sind wichtige Informationen und müssen leicht zu finden sein.

• Standard für den Besitz von Objekten in früheren Versionen von SQL Server oder das Schema, in dem es für 2005 und höher vorhanden sein sollte. Es ist Ihr Aufruf, was es ist, aber Sie sollten niemals raten, wem etwas gehört / wo es lebt. Wenn möglich, sollte das Schema / der Eigentümer in die CREATE-Skripte aufgenommen werden, um die Möglichkeit einer falschen Erstellung zu minimieren.

• Ein Indikator dafür, dass jeder, der SELECT * verwendet, dazu gebracht wird, ein halbes Liter seines eigenen Urins zu trinken.

• Sofern es keinen wirklich, wirklich guten Grund gibt (der Ihre Faulheit nicht einschließt), müssen Sie die Beziehungen zwischen Primärschlüssel und Fremdschlüssel von Anfang an haben, durchsetzen und aufrechterhalten. Dies ist schließlich eine relationale Datenbank, keine Flatfile, und verwaiste Datensätze werden Ihr Support-Leben irgendwann zur Hölle machen. Bitte beachten Sie auch, dass ich Ihnen versprechen kann, dass Sie es nach dem Ereignis nie schaffen werden, wenn Sie es jetzt nicht tun, da es zehnmal so viel Arbeit kostet, sobald Sie Daten haben (was ein bisschen durcheinander ist, weil Sie es nie erzwungen haben die Beziehungen richtig).

Ich bin mir sicher, dass ich etwas verpasst habe, aber für mich sind es diejenigen, die in einer anständigen Anzahl von Situationen tatsächlich einen echten Nutzen bieten.

Aber wie bei allen Standards ist weniger mehr. Je länger Ihre Codierungsstandards sind, desto weniger wahrscheinlich ist es, dass Benutzer sie lesen und verwenden. Sobald Sie ein paar gut verteilte Seiten hinter sich haben, versuchen Sie, die Dinge zu löschen, die in der realen Welt keinen wirklichen praktischen Unterschied machen, weil Sie nur die Wahrscheinlichkeit verringern, dass Leute etwas davon tun.

BEARBEITEN: Zwei Korrekturen - einschließlich Schemata im Eigentümerbereich, Entfernen eines fehlerhaften Hinweises zur Anzahl (*) - siehe Kommentare unten.

Es scheint keine Ressourcen für den Konsens darüber zu geben, was gut geschriebenes SQL bestimmt

Das liegt daran, dass es keinen Konsens gibt. Nur als Beispiel hätte ich unterschiedliche Antworten für mindestens die Hälfte der Elemente in Jon Hopkins 'Liste, und basierend auf der Menge an Details auf seiner Liste ist es eine sichere Vermutung, dass wir beide beruflich mit Datenbanken arbeiten.

Trotzdem ist ein Codierungsstandard immer noch eine gute Sache, und ein Standard, den jeder im Team versteht und dem er zustimmt, ist eine bessere Sache, da dieser Standard mit größerer Wahrscheinlichkeit eingehalten wird.

Zusätzlich zu Jon Hopkins 'Antwort ...

• Trennen Sie interne und externe Objekte

  • IX, UQ, TRG, CK usw. für Einschränkungen und Indizes usw.
  • Kleinbuchstaben oder CapsCase für Kunden, z. B. uspThing_Add

• Machen Sie sie für interne Objekte explizit, wenn "nicht Standard"

  • UQ = eindeutige Einschränkung
  • UQC = eindeutige Clusterbedingung
  • PK = Primärschlüssel
  • PKN = nicht gruppierter Primärschlüssel
  • IX = Index
  • IXU = eindeutiger Index
  • IXC = Clustered Index
  • IXCU oder IXUC = eindeutiger Clustered-Index

• Verwenden Sie Schemas, um die Benennung + Berechtigungen zu vereinfachen. Beispiele:

  • Helper.xxx für interne Prozesse
  • HelperFn.xxx für udfs
  • WebGUI.xxx für einen gegenüberliegenden Code
  • Daten und / oder Verlauf und / oder Bereitstellung für Tabellen