In der Datenbankwelt gibt es einige Dinge, über die man sich allgemein einig ist. Erhöhter RAM ist für DMBS-Systeme weitgehend vorteilhaft. Das Verteilen von Daten und Protokolldateien auf RAID verbessert die Leistung.
Namenskonventionen gehören nicht dazu.
Dies ist ein überraschend polarisierendes Thema, bei dem die Befürworter verschiedener Methodologien fest in ihren Positionen verankert sind. Und sehr lautstark und leidenschaftlich in ihrer Verteidigung derselben.
Dieser Artikel wird sich mit einigen der spezifischen Konventionen und Argumenten auf beiden Seiten befassen und gleichzeitig versuchen, für jeden Punkt eine vernünftige Schlussfolgerung zu ziehen.
Die große Pluralisierungsdebatte
Im Kern ist dies ein einfaches Thema. Wie benennt man beispielsweise eine Tabelle mit Kundeninformationen in einem relationalen Datenbankschema korrekt? Ist es Customer oder Customers ?
Argumente auf beiden Seiten gibt es zuhauf.
Auf den ersten Blick , ist es natürlich, im Plural an eine Sammlung von Objekten zu denken. Eine Gruppe von mehreren Einzelpersonen oder Unternehmen wäre Kunden . Daher sollte eine Tabelle (als Sammlung von Objekten) im Plural genannt werden. Eine einzelne Zeile in dieser Tabelle wäre ein einzelner Kunde .
Die Benennungsprinzipien von ISO/IEC sind zwar veraltet, empfehlen jedoch Tabellennamen im Plural und Spaltennamen im Singular.
Die meisten SQL Server-Systemtabellen verwenden Pluralnamen (sysnotifications , Systemoperatoren ), aber das ist widersprüchlich. Warum sysproxylogin und nicht sysproxylogins ?
In Argumenten für mehrere Tabellennamen werden Zeilen in einer Tabelle auch als „Instanzen“ eines Ganzen referenziert – ähnlich wie Elemente in einer Sammlung. Kunden definiert den gesamten Satz; ein einzelner Kunde ist eine Instanz von Kunden .
Umgekehrt gibt es viele Gründe, singuläre Objektnamen zu verwenden.
Auch wenn es viele Artikel (oder Kunden) geben kann ) in einer Tabelle kann die Tabelle selbst als einzelne Entität betrachtet werden. Eine Kundenbox ist keine „Kundenbox“, auch wenn sie eine große Anzahl von Kunden enthält. Außerdem kann die Tabelle nur ein Element – oder gar kein Element – enthalten, was „Kunden“ zu einer falschen Bezeichnung macht.
Wenn Sie den Tabellennamen basierend auf Wortvarianten ändern, können schnell Inkonsistenzen entstehen. Während viele Wörter einfach sind (Kunde zu Kunden werden , Produkt wird zu Produkten ), andere Wörter möglicherweise nicht. In diesem Fall Person könnten zu Personen werden oder Personen; ein einzigartiger Elch genauso aussehen würde wie seine Pluralform Moose . (Aber wozu braucht man einen Elchtisch?) Eine Konvention wie People.FirstName beginnt verwirrend unklar zu werden.
Wenn mehrere Sprachen involviert sind, wird die Situation noch schlimmer. Da die Pluralisierung von Wörtern auf so viele Arten variieren kann (Kunden, Mäuse, Elche, Kinder, Krisen, Lehrpläne, Flugzeuge), haben Nicht-Muttersprachler zusätzliche Herausforderungen. Das Festhalten an singulären Objektnamen vermeidet dieses Problem vollständig.
Die Fallkonventionsfrage
Es gibt nicht die gleiche Leidenschaft für Fallkonventionen wie für Pluralisierung, aber es werden Argumente für mehrere verschiedene Optionen vorgebracht. Dazu gehören:
- Pascal-Fall :Der erste Buchstabe jedes verketteten Wortes wird großgeschrieben, wie in:
CustomerOrder -
Camel Case :Der erste Buchstabe des ersten Wortes ist klein geschrieben; alle nachfolgenden verketteten Wörter haben einen großen Anfangsbuchstaben, wie in:
customerOrderPascal Case wird manchmal als Untertyp von Camel Case angesehen, aber Microsoft unterscheidet im Allgemeinen zwischen den beiden.
Für Wörter mit weniger als drei Zeichen wird empfohlen, nur Großbuchstaben zu verwenden, wie in
UIoderIO. - Unterstreichen Sie [„C“-Fall] :Wörter werden durch Unterstriche getrennt, wie in
Customer_Order, odercustomer_Order– noch mehr Entscheidungen!
Forscher der Johns Hopkins University führten eine Studie über die Effizienz der Verwendung von Unterstrichen bei der Programmierung von Objektnamen durch. Sie fanden heraus, dass die Verwendung von Camel Case (oder Pascal Case) die Tippgenauigkeit und -erkennung verbesserte. Unterstriche wurden in der C-Programmierung häufig verwendet, aber der Trend geht in Richtung Camel/Pascal Case mit neuerem Schwerpunkt auf Sprachen im Stil von Microsoft und Java.
Wie bei den anderen Themen folgt eine etablierte Konvention ist wichtiger als die Auswahl der Konvention selbst.
Eine zusätzliche Überlegung ist hier die Groß-/Kleinschreibung der Datenbank. Die SQL Server-Sortierung bestimmt diese Sensibilität mit „CS“ (Groß-/Kleinschreibung beachten) oder „CI“ (Groß-/Kleinschreibung beachten) im Sortierungsnamen. Zum Beispiel:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Bei Sortierungen mit Berücksichtigung der Groß-/Kleinschreibung Select * from myTable würde gegen das Objekt MyTable . Dadurch sind Unterstriche möglicherweise etwas vorzuziehen, um Verwirrung zu vermeiden, aber Intellisense hilft auch, Tippfehler in den meisten modernen Programmierumgebungen zu beseitigen.
Andere Überlegungen zur Namenskonvention
Bei der Singular-vs.-Plural-Debatte und der Great-Case-Frage mag der Kampf am heftigsten ausgetragen werden, aber es gibt mindestens drei weitere Bereiche, die man im Hinterkopf behalten sollte, wenn man eine Namenskonvention in Erwägung zieht.
Vermeiden Sie die Verwendung von SQL Server-reservierten Wörtern als Objektnamen. Dies umfasst sowohl Tabellen als auch Spalten. Zum Beispiel – Benutzer , Uhrzeit , und Datum sind reserviert. Reservierte Schlüsselwörter erfordern je nach aufrufender Anwendung möglicherweise zusätzliche Sorgfalt beim Verweis (z. B. die Verwendung von eckigen Klammern). Dies gilt auch für Leerzeichen. Leerzeichen in Objektnamen erfordern Anführungszeichen zum Verweisen.
Dazu passt auch eine weitere Empfehlung – Präzision. System.CreateDate ist viel klarer als System.Date . Ein gut gestaltetes Modell ermöglicht es dem Betrachter, den Zweck der zugrunde liegenden Objekte sofort zu verstehen. Wenn Bezeichner als Fremdschlüssel referenziert werden sollen, seien Sie beim Namen großzügig – Customer.CustomerID statt Customer.ID .
Vermeiden Sie Präfixe und Suffixe für Tabellen und Ansichten , wie zum Beispiel tblTable . Die ungarische Notation (die immer dazu gedacht war, die Verwendung von Variablen zu kennzeichnen) ist in die gängigen Namenskonventionen von SQL Server gerutscht, wird jedoch weithin verspottet. Objektbezeichner sollten beschreiben, was darin enthalten ist, nicht das Objekt selbst.
Präfixe sind jedoch in SQL Server-unterstützenden Objekten nützlich , da sie die funktionale Natur des Objekts beschreiben.
Die folgenden sind allgemein akzeptierte Präfixe für SQL Server-Objekte:
- IX:Inhaltsverzeichnis
- PK:Primärschlüssel
- FK:Fremdschlüssel
- CK:Einschränkung prüfen
- DF:Standard
- UQ wird manchmal auch für eindeutige Indizes verwendet.
Dieses Modell veranschaulicht die oben definierten Punkte. Es bedarf keiner Erläuterung zur Art der Daten; Es werden einheitliche Namenskonventionen verwendet und eindeutige Identifikatoren sind vorhanden.
Am Ende gibt es Vor- und Nachteile für beide Seiten der Konventionsnamensdebatte. Es gibt jedoch einen wichtigen Punkt, auf den sich beide Seiten einigen können:Seien Sie unabhängig von den getroffenen Entscheidungen konsistent mit der gewählten Konvention.
Welche SQL-Namenskonventionen verwenden Sie und warum?
