Namenskonventionen für Datenbanken, Tabellen und Spalten?[geschlossen]

https://stackoverflow.com/questions/7662

08-06-2019
|

Frage

Wenn ich eine Datenbank entwerfe, frage ich mich immer, ob es eine beste Möglichkeit gibt, ein Element in meiner Datenbank zu benennen.Sehr oft stelle ich mir folgende Fragen:

Sollten Tabellennamen im Plural stehen?
Sollten Spaltennamen singulär sein?
Soll ich Tabellen oder Spalten ein Präfix voranstellen?
Sollte ich bei der Benennung von Elementen die Groß-/Kleinschreibung verwenden?

Gibt es empfohlene Richtlinien für die Benennung von Elementen in einer Datenbank?

Lösung

Ich empfehle einen Blick auf die SQL Server-Beispieldatenbanken von Microsoft:https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

Das AdventureWorks-Beispiel verwendet eine sehr klare und konsistente Namenskonvention, die Schemanamen für die Organisation von Datenbankobjekten verwendet.

Singularnamen für Tabellen
Singularnamen für Spalten
Schemaname für Tabellenpräfix (z. B.:SchemeName.TableName)
Pascal-Gehäuse (auch bekannt alsoberes Kamelgehäuse)

Andere Tipps

Späte Antwort hier, aber kurz gesagt:

Mein Präferenz ist Plural
Ja
Tische:*Normalerweise* sind keine Präfixe am besten. Säulen:NEIN.
Sowohl Tabellen als auch Spalten:PascalCase.

Ausarbeitung:

(1) Was Sie tun müssen. Es gibt nur sehr wenige Dinge, die Sie muss tun Sie jedes Mal eine bestimmte Art und Weise, aber es gibt einige.

Nenne deinen Primärschlüssel unter Verwendung des Formats „[singularOfTableName]ID“.Das heißt, ob Ihr Tabellenname lautet Kunde oder Kunden, der Primärschlüssel sollte sein Kundennummer.
Weiter, fremde Schlüssel muss einheitlich benannt werden in verschiedenen Tabellen.Es sollte legal sein, jemanden zu verprügeln, der dies nicht tut.Ich würde behaupten, dass es zwar definierte Fremdschlüsseleinschränkungen gibt oft Wichtig ist eine konsistente Fremdschlüsselbenennung stets wichtig
Ihre Datenbank muss vorhanden sein interne Konventionen.Auch wenn Sie in späteren Abschnitten sehen werden, dass ich sehr flexibel bin, innerhalb Die Benennung einer Datenbank muss sehr konsistent sein.Ob Ihr Tisch für Kunden heißt Kunden oder Kunde ist weniger wichtig, als dass Sie es in derselben Datenbank auf die gleiche Weise tun.Und Sie können eine Münze werfen, um zu bestimmen, wie Unterstriche verwendet werden, aber dann Sie müssen sie weiterhin auf die gleiche Weise verwenden.Wenn Sie dies nicht tun, sind Sie ein schlechter Mensch und sollten ein geringes Selbstwertgefühl haben.

(2) Was Sie wahrscheinlich tun sollten.

Felder, die dieselbe Art von Daten in verschiedenen Tabellen darstellen sollen gleich genannt werden.Auf einer Tabelle darf nicht „Zip“ und auf einer anderen „ZipCode“ stehen.
Um Wörter in Ihren Tabellen- oder Spaltennamen zu trennen, verwenden Sie PascalCasing.Die Verwendung von camelCasing wäre an sich nicht problematisch, aber das ist nicht die Konvention und es würde lustig aussehen.Auf Unterstriche gehe ich gleich ein.(Sie dürfen Großbuchstaben nicht mehr wie früher verwenden.OBNOXIOUSTABLE.ANNOYING_COLUMN war in DB2 vor 20 Jahren in Ordnung, aber nicht jetzt.)
Verkürzen oder kürzen Sie Wörter nicht künstlich.Es ist besser, dass ein Name lang und klar ist, als kurz und verwirrend.Ultrakurze Namen sind ein Überbleibsel aus dunkleren, wilderen Zeiten.Cus_AddRef.Was zum Teufel ist das?Referenz des Verwahradressaten?Zusätzliche Rückerstattung für den Kunden?Benutzerdefinierte Adressverweisung?

(3) Was Sie beachten sollten.

Ich finde wirklich, dass man für Tabellen mehrere Namen haben sollte;manche denken singulär.Lesen Sie die Argumente woanders.Spaltennamen sollten jedoch singulär sein.Selbst wenn Sie mehrere Tabellennamen verwenden, stehen Tabellen, die Kombinationen anderer Tabellen darstellen, möglicherweise im Singular.Wenn Sie beispielsweise eine haben Werbeaktionen und ein Artikel Tabelle, eine Tabelle, die einen Artikel darstellt, der Teil einer Werbeaktion ist, könnte Promotions_Items sein, aber meiner Meinung nach könnte es auch berechtigterweise Promotion_Items sein (was die Eins-zu-viele-Beziehung widerspiegelt).
Verwenden Sie Unterstriche konsequent und für einen bestimmten Zweck.Nur allgemeine Tabellennamen sollten mit PascalCasing klar genug sein;Sie benötigen keine Unterstriche, um Wörter zu trennen.Speichern Sie Unterstriche entweder (a) zur Angabe einer assoziativen Tabelle oder (b) zur Präfixierung, worauf ich im nächsten Punkt eingehen werde.
Präfixe sind weder gut noch schlecht.Es normalerweise ist nicht das Beste.In Ihrer ersten oder zweiten Datenbank würde ich nicht empfehlen, Präfixe für die allgemeine thematische Gruppierung von Tabellen zu verwenden.Tabellen passen am Ende nicht so einfach in Ihre Kategorien, und das kann tatsächlich der Fall sein Schwerer Tische finden.Mit der Erfahrung können Sie ein Präfixschema planen und anwenden, das mehr nützt als schadet.Ich habe einmal in einer Datenbank gearbeitet, mit der Datentabellen begannen Tabl, Konfigurationstabellen mit ctbl, Ansichten mit Vew, proc's sp, und udfs fn, und ein paar andere;Es wurde sorgfältig und konsequent angewendet, sodass es gut geklappt hat.Präfixe BENÖTIGEN Sie nur dann, wenn Sie wirklich separate Lösungen haben, die sich aus irgendeinem Grund in derselben Datenbank befinden.Das Voranstellen kann bei der Gruppierung der Tabellen sehr hilfreich sein.Für besondere Situationen ist das Präfix auch in Ordnung, etwa für temporäre Tabellen, die Sie hervorheben möchten.
Sehr selten (wenn überhaupt) möchten Sie Spalten vorfixieren.

Ok, da wir uns mit der Meinung auseinandersetzen:

Ich glaube, dass Tabellennamen im Plural stehen sollten.Tabellen sind eine Sammlung (eine Tabelle) von Entitäten.Jede Zeile stellt eine einzelne Entität dar und die Tabelle stellt die Sammlung dar.Daher würde ich eine Tabelle mit Personenentitäten „Personen“ (oder Personen, was auch immer Ihnen gefällt) nennen.

Für diejenigen, die in Abfragen gerne einzelne „Entitätsnamen“ sehen möchten, würde ich Tabellenaliase dafür verwenden:

SELECT person.Name
FROM People person

Ein bisschen wie LINQs „Von Person in Personen Person.Name auswählen“.

Was 2, 3 und 4 betrifft, stimme ich @Lars zu.

Ich arbeite in einem Datenbank-Support-Team mit drei DBAs und unsere in Betracht gezogenen Optionen sind:

Jeder Namensstandard ist besser als kein Standard.
Es gibt keinen „einzigen“ Standard, wir alle haben unsere Vorlieben
Wenn es bereits einen Standard gibt, verwenden Sie ihn.Erstellen Sie keinen weiteren Standard und verfälschen Sie nicht die bestehenden Standards.

Wir verwenden singuläre Namen für Tabellen.Tabellen werden in der Regel mit dem Namen des Systems (oder seinem Akronym) vorangestellt.Dies ist nützlich, wenn das System komplex ist, da Sie das Präfix ändern können, um die Tabellen logisch zu gruppieren (d. h.reg_customer, reg_booking und regadmin_limits).

Für Felder würden wir erwarten, dass Feldnamen das Präfix/Akryonm der Tabelle enthalten (d. h.cust_address1) und wir bevorzugen auch die Verwendung eines Standardsatzes von Suffixen ( _id für den PK, _cd für „Code“, _nm für „Name“, _nb für „Nummer“, _dt für „Datum“).

Der Name des Fremdschlüsselfelds sollte mit dem des Primärschlüsselfelds identisch sein.

d.h.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Wenn Sie ein neues Projekt entwickeln, empfehle ich Ihnen, alle bevorzugten Entitätsnamen, Präfixe und Akronyme aufzuschreiben und dieses Dokument Ihren Entwicklern zu geben.Wenn sie sich dann entscheiden, eine neue Tabelle zu erstellen, können sie auf das Dokument verweisen, anstatt zu „raten“, wie die Tabelle und die Felder heißen sollen.

NEIN.Eine Tabelle sollte nach der Entität benannt werden, die sie darstellt.„Person“ und nicht „Personen“ ist die Art und Weise, wie man sich auf denjenigen bezieht, den einer der Datensätze repräsentiert.
Wieder das Gleiche.Die Spalte FirstName sollte eigentlich nicht FirstNames heißen.Es hängt alles davon ab, was Sie mit der Spalte darstellen möchten.
NEIN.
Ja.Setzen Sie es aus Gründen der Klarheit in Großbuchstaben.Wenn Sie Spalten wie „Vorname“ benötigen, erleichtert die Groß-/Kleinschreibung die Lesbarkeit.

OK.Das sind meine 0,02 $

Ich befürworte außerdem eine Benennungskonvention im ISO/IEC 11179-Stil und stelle fest, dass es sich dabei eher um Richtlinien als um Vorschriften handelt.

Sehen Datenelementname auf Wikipedia:

„Tabellen sind Sammlungen von Entitäten und befolgen die Benennungsrichtlinien für Sammlungen.Idealerweise wird eine Sammelbezeichnung verwendet:z. B. Personal.Plural ist auch richtig:Mitarbeiter.Zu den falschen Namen gehören:Employee, tblEmployee und EmployeeTable.“

Wie immer gibt es Ausnahmen von den Regeln, z.B.Eine Tabelle, die immer genau eine Zeile hat, ist möglicherweise besser mit einem eindeutigen Namen, z. B.eine Konfigurationstabelle.Und Konsistenz ist von größter Bedeutung:Überprüfen Sie, ob in Ihrem Geschäft eine Konvention gilt, und wenn ja, befolgen Sie diese.Wenn es Ihnen nicht gefällt, erstellen Sie ein Business Case, um es zu ändern, anstatt der Einzelkämpfer zu sein.

Unsere Präferenz:

Sollten Tabellennamen im Plural stehen?
Niemals.Die Argumente dafür, dass es sich um eine Sammlung handelt, sind sinnvoll, aber man weiß nie, was die Tabelle enthalten wird (0,1 oder viele Elemente).Pluralregeln machen die Benennung unnötig kompliziert.1 Haus, 2 Häuser, Maus gegen Mäuse, Mensch gegen Mensch, und wir haben uns noch nicht einmal mit anderen Sprachen befasst.

Update person set property = 'value' wirkt auf jede Person in der Tabelle.
Select * from person where person.name = 'Greg' gibt eine Sammlung/einen Zeilensatz von Personenzeilen zurück.
Sollten Spaltennamen singulär sein?
Normalerweise ja, es sei denn, Sie verstoßen gegen die Normalisierungsregeln.
Soll ich Tabellen oder Spalten ein Präfix voranstellen?
Meistens eine Plattformpräferenz.Wir ziehen es vor, Spalten den Tabellennamen voranzustellen.Wir stellen keine Tabellen voran, wohl aber Ansichten (v_) und gespeicherte_Prozeduren (sp_ oder f_ (Funktion)).Das hilft Leuten, die versuchen möchten, v_person.age zu aktualisieren, bei dem es sich eigentlich um ein berechnetes Feld in einer Ansicht handelt (das ohnehin nicht aktualisiert werden kann).

Es ist auch eine großartige Möglichkeit, Schlüsselwortkollisionen zu vermeiden (delivery.from bricht ab, Delivery_from jedoch nicht).

Dadurch wird der Code ausführlicher, die Lesbarkeit wird jedoch häufig verbessert.

bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
...ist sehr lesbar und eindeutig.Das kann allerdings außer Kontrolle geraten:

customer.customer_customer_type_id

Zeigt eine Beziehung zwischen Kunde und der Tabelle „customer_type“ an, gibt den Primärschlüssel in der Tabelle „customer_type“ (customer_type_id) an und wenn Sie beim Debuggen einer Abfrage jemals „customer_customer_type_id“ sehen, wissen Sie sofort, woher er stammt (Tabelle „customer“).

oder wenn Sie eine M-M-Beziehung zwischen customer_type und customer_category haben (für bestimmte Kategorien sind nur bestimmte Typen verfügbar)

customer_category_customer_type_id

...ist etwas (!) zu lang.
Sollte ich bei der Benennung von Elementen die Groß-/Kleinschreibung verwenden?Ja – Kleinschreibung :), mit Unterstrichen.Diese sind sehr gut lesbar und plattformübergreifend.Zusammen mit 3 oben macht es auch Sinn.

Die meisten davon sind jedoch Präferenzen.- Solange Sie konsistent sind, sollte es für jeden, der es lesen muss, vorhersehbar sein.

Ich höre ständig das Argument, dass es eine Frage des persönlichen Geschmacks sei, ob eine Tabelle pluralisiert sei oder nicht, und dass es keine Best Practice gebe.Ich glaube nicht, dass das stimmt, insbesondere als Programmierer und nicht als DBA.Soweit mir bekannt ist, gibt es keine legitimen Gründe für die Pluralform eines Tabellennamens außer „Es macht für mich einfach Sinn, weil es eine Sammlung von Objekten ist“, während es legitime Vorteile im Code gibt, wenn singuläre Tabellennamen verwendet werden.Zum Beispiel:

Es vermeidet Fehler und Fehler, die durch Mehrdeutigkeiten im Plural entstehen.Programmierer sind nicht gerade für ihre Rechtschreibkenntnisse bekannt und die Pluralisierung einiger Wörter ist verwirrend.Endet das Pluralwort beispielsweise auf „es“ oder nur auf „s“?Handelt es sich um Personen oder Menschen?Wenn Sie mit großen Teams an einem Projekt arbeiten, kann dies zu einem Problem werden.Beispielsweise ein Fall, in dem ein Teammitglied die falsche Methode verwendet, um eine von ihm erstellte Tabelle zu pluralisieren.Wenn ich mit dieser Tabelle interagiere, wird sie überall in Code verwendet, auf den ich keinen Zugriff habe oder dessen Korrektur zu lange dauern würde.Das Ergebnis ist, dass ich jedes Mal daran denken muss, die Tabelle falsch zu buchstabieren, wenn ich sie verwende.Etwas ganz Ähnliches ist mir passiert.Je einfacher Sie es jedem Mitglied des Teams ermöglichen können, konsistent und einfach die genauen, korrekten Tabellennamen zu verwenden, ohne Fehler zu machen oder ständig nach Tabellennamen suchen zu müssen, desto besser.Die Einzelversion ist in einer Teamumgebung viel einfacher zu handhaben.
Wenn Sie die singuläre Version eines Tabellennamens verwenden UND dem Primärschlüssel den Tabellennamen voranstellen, haben Sie jetzt den Vorteil, dass Sie einfach über Code allein einen Tabellennamen aus einem Primärschlüssel oder umgekehrt ermitteln können.Sie können eine Variable mit einem Tabellennamen erhalten, „Id“ an das Ende anhängen und erhalten nun per Code den Primärschlüssel der Tabelle, ohne eine zusätzliche Abfrage durchführen zu müssen.Oder Sie können „Id“ vom Ende eines Primärschlüssels abschneiden, um per Code einen Tabellennamen zu ermitteln.Wenn Sie „id“ ohne Tabellennamen für den Primärschlüssel verwenden, können Sie den Tabellennamen nicht per Code aus dem Primärschlüssel ermitteln.Darüber hinaus verwenden die meisten Leute, die Tabellennamen pluralisieren und PK-Spalten den Tabellennamen voranstellen, die singuläre Version des Tabellennamens im PK (zum Beispiel statuses und statusId), was es überhaupt unmöglich macht, dies zu tun.
Wenn Sie Tabellennamen im Singular festlegen, können Sie dafür sorgen, dass sie mit den Klassennamen übereinstimmen, die sie darstellen.Dies kann wiederum den Code vereinfachen und es Ihnen ermöglichen, wirklich nette Dinge zu tun, wie zum Beispiel eine Klasse zu instanziieren, indem Sie nur den Tabellennamen haben.Außerdem wird dadurch Ihr Code konsistenter, was zu ... führt.
Wenn Sie den Tabellennamen im Singular festlegen, ist Ihr Benennungsschema an jedem Ort konsistent, organisiert und leicht zu verwalten.Sie wissen, dass es sich in jedem Fall in Ihrem Code, sei es in einem Spaltennamen, als Klassenname oder als Tabellenname, um den exakt gleichen Namen handelt.Dies ermöglicht Ihnen eine globale Suche, um überall zu sehen, wo Daten verwendet werden.Wenn Sie einen Tabellennamen pluralisieren, gibt es Fälle, in denen Sie die singuläre Version dieses Tabellennamens verwenden (die Klasse, in die er umgewandelt wird, im Primärschlüssel).Es macht einfach Sinn, dass Ihre Daten in einigen Fällen nicht im Plural und in einigen Fällen im Singular bezeichnet werden.

Um es zusammenzufassen: Wenn Sie Ihre Tabellennamen pluralisieren, verlieren Sie alle möglichen Vorteile, indem Sie Ihren Code intelligenter und einfacher zu handhaben machen.Es kann sogar Fälle geben, in denen Sie Nachschlagetabellen/-arrays benötigen, um Ihre Tabellennamen in Objekt- oder lokale Codenamen umzuwandeln, die Sie hätten vermeiden können.Singulare Tabellennamen mögen sich zunächst vielleicht etwas seltsam anfühlen, bieten aber erhebliche Vorteile gegenüber pluralisierten Namen und sind meiner Meinung nach die beste Vorgehensweise.

Schauen Sie sich ISO 11179-5 an:Benennungs- und Identifizierungsprinzipien Sie können es hier bekommen: http://metadata-standards.org/11179/#11179-5

Ich habe vor einiger Zeit hier darüber gebloggt: ISO-11179-Namenskonventionen

Ich weiß, dass dies zu spät ist und die Frage bereits sehr gut beantwortet wurde, aber ich möchte meine Meinung zu Punkt 3 bezüglich der Präfixierung von Spaltennamen äußern.

Alle Spalten sollten mit einem Präfix benannt werden, das für die Tabelle, in der sie definiert sind, eindeutig ist.

Z.B.Angesichts der Tabellen „customer“ und „address“ verwenden wir die Präfixe „cust“ bzw. „addr“.„Kunde“ hätte „cust_id“, „cust_name“ usw.drin.„Adresse“ hätte „addr_id“, „addr_cust_id“ (FK zurück zum Kunden), „addr_street“ usw.drin.

Als mir dieser Standard zum ersten Mal präsentiert wurde, war ich strikt dagegen;Ich hasste die Idee.Ich konnte die Vorstellung von all dem zusätzlichen Tippen und der Redundanz nicht ertragen.Jetzt habe ich genug Erfahrung damit, dass ich nie wieder zurückgehen würde.

Dies führt dazu, dass alle Spalten in Ihrem Datenbankschema eindeutig sind.Dies hat einen großen Vorteil, der alle Argumente dagegen übertrifft (meiner Meinung nach natürlich):

Sie können Ihre gesamte Codebasis durchsuchen und zuverlässig jede Codezeile finden, die eine bestimmte Spalte berührt.

Der Vorteil von Nr. 1 ist unglaublich groß.Ich kann eine Spalte verwerfen und weiß genau, welche Dateien aktualisiert werden müssen, bevor die Spalte sicher aus dem Schema entfernt werden kann.Ich kann die Bedeutung einer Spalte ändern und weiß genau, welcher Code umgestaltet werden muss.Oder ich kann einfach feststellen, ob Daten aus einer Spalte überhaupt in einem bestimmten Teil des Systems verwendet werden.Ich kann nicht zählen, wie oft dadurch aus einem möglicherweise riesigen Projekt ein einfaches wurde, und auch nicht, wie viele Stunden wir bei der Entwicklungsarbeit eingespart haben.

Ein weiterer, relativ kleiner Vorteil besteht darin, dass Sie bei einem Self-Join nur Tabellenaliase verwenden müssen:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Meine Meinung dazu ist:

1) Nein, Tabellennamen sollten singulär sein.

Während es für die einfache Auswahl sinnvoll erscheint (select * from Orders) macht es für das OO-Äquivalent (Orders x = new Orders).

Eine Tabelle in einer Datenbank ist eigentlich die Menge dieser Entität. Es macht mehr Sinn, wenn Sie Set-Logik verwenden:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Diese letzte Zeile, die eigentliche Logik des Joins, sieht bei mehreren Tabellennamen verwirrend aus.

Ich bin mir nicht sicher, ob die Verwendung eines Alias (wie Matt vorschlägt) das klären soll.

2) Sie sollten singulär sein, da sie nur eine Eigenschaft besitzen

3) Niemals, wenn der Spaltenname mehrdeutig ist (wie oben, wo beide eine Spalte namens [Schlüssel] haben), kann der Name der Tabelle (oder ihr Alias) sie gut genug unterscheiden.Sie möchten, dass Abfragen schnell eingegeben werden können und einfach sind – Präfixe erhöhen die Komplexität unnötig.

4) Was auch immer Sie wollen, ich würde Ihnen CapitalCase empfehlen

Ich glaube nicht, dass es für irgendetwas davon eine Reihe absoluter Richtlinien gibt.

Solange das, was Sie auswählen, in der gesamten Anwendung oder Datenbank konsistent ist, denke ich nicht, dass es wirklich wichtig ist.

Meiner Meinung nach:

Tabellennamen sollten im Plural stehen.
Spaltennamen sollten singulär sein.
NEIN.
Entweder CamelCase (mein Favorit) oder underscore_separated sowohl für Tabellennamen als auch für Spaltennamen.

Allerdings ist, wie bereits erwähnt, jede Konvention besser als keine Konvention.Unabhängig davon, wie Sie vorgehen, dokumentieren Sie es, damit zukünftige Änderungen denselben Konventionen folgen.

Halten Sie Tischnamen auf jeden Fall im Singular, also Personen, nicht Personen
1. Ebenfalls
2. NEIN.Ich habe einige schreckliche Präfixe gesehen, die sogar besagten, dass es sich um eine Tabelle (tbl_) oder eine Benutzerspeicherprozedur (usp_) handelte.Darauf folgt der Datenbankname...Tu es nicht!
3. Ja.Ich tendiere dazu, alle meine Tabellennamen in PascalCase zu schreiben

Ich denke, die beste Antwort auf jede dieser Fragen würden Sie und Ihr Team geben.Es ist weitaus wichtiger, eine Namenskonvention zu haben, als wie genau die Namenskonvention lautet.

Da es darauf keine richtige Antwort gibt, sollten Sie sich etwas Zeit nehmen (aber nicht zu viel) und Ihre eigenen Konventionen wählen und – hier ist Das Wichtigste: Bleiben Sie dabei.

Natürlich ist es gut, sich über die entsprechenden Standards zu informieren, denn das ist genau das, wonach Sie fragen, aber machen Sie sich keine Sorgen über die Anzahl der unterschiedlichen Antworten, die Sie erhalten könnten:Wählen Sie diejenige, die für Sie besser erscheint.

Nur für den Fall, hier sind meine Antworten:

Ja.Eine Tabelle ist eine Gruppe von Aufzeichnungen, Lehrer oder Schauspieler, Also...Plural.
Ja.
Ich benutze sie nicht.
Die Datenbank, die ich häufiger verwende – Firebird – speichert alles in Großbuchstaben, sodass es keine Rolle spielt.Wie auch immer, wenn ich programmiere, schreibe ich die Namen so, dass sie leichter zu lesen sind Erscheinungsjahr.

Namenskonventionen ermöglichen es dem Entwicklungsteam, die Auffindbarkeit und Wartbarkeit in den Mittelpunkt des Projekts zu stellen.

Die Entwicklung einer guten Namenskonvention braucht Zeit, aber wenn sie erst einmal vorhanden ist, kann das Team mit einer gemeinsamen Sprache vorankommen.Eine gute Namenskonvention wächst organisch mit dem Projekt.Eine gute Namenskonvention bewältigt problemlos Änderungen während der längsten und wichtigsten Phase des Software-Lebenszyklus – dem Service-Management in der Produktion.

Hier sind meine Antworten:

Ja, Tabellennamen sollten im Plural stehen, wenn sie sich auf eine Reihe von Tabellen beziehen Geschäfte, Wertpapiere, oder Gegenparteien Zum Beispiel.
Ja.
Ja.SQL-Tabellen wird das Präfix tb_ vorangestellt, Ansichten das Präfix vw_, gespeicherten Prozeduren das Präfix usp_ und Triggern das Präfix tg_ gefolgt vom Datenbanknamen.
Der Spaltenname sollte aus Kleinbuchstaben bestehen und durch einen Unterstrich getrennt werden.

Benennung ist schwierig, aber in jeder Organisation gibt es jemanden, der Dinge benennen kann, und in jedem Softwareteam sollte es jemanden geben, der die Verantwortung für Benennungsstandards übernimmt und sicherstellt, dass Benennungsprobleme wie sec_id, sec_value Und security_id frühzeitig gelöst werden, bevor sie in das Projekt integriert werden.

Was sind also die Grundprinzipien einer guten Namenskonvention und Standards:-

Verwenden Sie die Sprache Ihres Kunden und Ihre Lösungsdomäne
Seien Sie beschreibend
Seien Sie konsequent
Klären, reflektieren und umgestalten
Verwenden Sie keine Abkürzungen, es sei denn, sie sind für alle klar
Verwenden Sie keine SQL -reservierten Schlüsselwörter als Spaltennamen

Hier ist ein Link, der einige Auswahlmöglichkeiten bietet.Ich suchte nach einer einfachen Spezifikation, der ich folgen konnte, anstatt mich auf eine teilweise definierte Spezifikation verlassen zu müssen.

http://justinsomnia.org/writings/naming_conventions.html

Tabellennamen sollten immer singulär sein, da sie eine Menge von Objekten darstellen.Wie Sie Herde sagen, um eine Gruppe von Schafen zu bezeichnen, oder Herde, um eine Gruppe von Vögeln zu bezeichnen.Kein Plural erforderlich.Wenn ein Tabellenname aus zwei Namen besteht und die Namenskonvention im Plural besteht, ist es schwierig zu wissen, ob der Pluralname das erste oder zweite Wort oder beides sein soll.Es ist die Logik – Object.instance, nicht Objects.instance.Oder TableName.column, nicht TableNames.column(s).Microsoft SQL unterscheidet nicht zwischen Groß- und Kleinschreibung. Tabellennamen lassen sich leichter lesen, wenn Großbuchstaben verwendet werden, um Tabellen- oder Spaltennamen zu trennen, wenn sie aus zwei oder mehr Namen bestehen.

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Tabellenname: Es sollte singulär sein, da es sich um eine singuläre Entität handelt, die ein Objekt der realen Welt darstellt, und nicht um Objekte, die singulär sind.

Spaltenname: Es sollte nur dann singulär sein, wenn es vermittelt, dass es einen atomaren Wert hat und die Normalisierungstheorie bestätigt.Wenn es jedoch n Eigenschaften gleicher Art gibt, sollten diese mit 1, 2, ..., n usw. angehängt werden.

Tabellen/Spalten voranstellen:Es ist ein riesiges Thema, das später besprochen wird.

Gehäuse:Es sollte ein Camel-Gehäuse sein

Mein Freund, Patrick Karcher, Ich bitte Sie, bitte nichts zu schreiben, was für jemanden anstößig sein könnte, da Sie geschrieben haben: „Fernschlüssel müssen außerdem in verschiedenen Tabellen konsistent benannt werden.“Es sollte legal sein, jemanden zu verprügeln, der dies nicht tut.Ich habe diesen Fehler noch nie gemacht, mein Freund Patrick, aber ich schreibe im Allgemeinen.Was wäre, wenn sie gemeinsam planen, dich dafür zu schlagen?:) :)

Sehr spät zur Party, aber ich wollte trotzdem meine Meinung zu Spaltenpräfixen hinzufügen

Es scheint zwei Hauptargumente für die Verwendung des Namensstandards table_column (oder tableColumn) für Spalten zu geben, beide basieren auf der Tatsache, dass der Spaltenname selbst in Ihrer gesamten Datenbank eindeutig ist:

1) Sie müssen in Ihren Abfragen nicht ständig Tabellennamen und/oder Spaltenaliase angeben

2) Sie können ganz einfach Ihren gesamten Code nach dem Spaltennamen durchsuchen

Ich halte beide Argumente für fehlerhaft.Die Lösung beider Probleme ohne Verwendung von Präfixen ist einfach.Hier ist mein Vorschlag:

Verwenden Sie in Ihrer SQL immer den Tabellennamen.Verwenden Sie beispielsweise immer table.column anstelle von Column.

Es löst offensichtlich 2), da Sie jetzt einfach nach table.column anstelle von table_column suchen können.

Aber ich kann dich schreien hören, wie löst es 1)?Es ging genau darum, dies zu vermeiden.Ja, das stimmte, aber die Lösung war schrecklich fehlerhaft.Warum?Nun, die Präfixlösung läuft auf Folgendes hinaus:
Um zu vermeiden, dass bei Unklarheiten table.column angegeben werden muss, benennen Sie alle Ihre Spalten table_column!
Dies bedeutet jedoch, dass Sie von nun an bei jeder Angabe einer Spalte IMMER den Spaltennamen eingeben müssen.Aber wenn Sie das trotzdem tun müssen, welchen Vorteil hat es dann, wenn table.column immer explizit geschrieben wird?Genau, es gibt keinen Vorteil, es ist genau die gleiche Anzahl an Zeichen einzugeben.

bearbeiten:Ja, mir ist bewusst, dass die Benennung der Spalten mit dem Präfix die korrekte Verwendung erzwingt, während mein Ansatz auf den Programmierern beruht

Grundlegende Konventionen (und Stile) für die Benennung von Datenbanken (Klicken Sie hier für eine detailliertere Beschreibung)

Tabellennamen Wählen Sie kurze, eindeutige Namen, wobei nicht mehr als ein oder zwei Wörter Tabellen unterscheiden, die die Benennung eindeutiger Feldnamen sowie Such- und Verknüpfungstabellen geben, geben Tabellen einzigartige Namen, niemals plural (Update: Update:Ich stimme immer noch mit den Gründen für diese Konvention überein, aber die meisten Leute mögen Tabellennamen im Plural wirklich, deshalb habe ich meine Haltung abgeschwächt) ...Folgen Sie bitte dem Link oben

Tabellennamen im Singular.Nehmen wir an, Sie modellieren eine Beziehung zwischen einer Person und ihrer Adresse.Wenn Sie beispielsweise ein Datamodel lesen, bevorzugen Sie "Jede Person kann bei 0,1 oder vielen Adresse leben." oder "Jedes Volk kann bei 0,1 oder vielen Adressen leben." Ich denke, es ist einfacher, die Adresse zu plurieren, anstatt Menschen als Person umformulieren zu müssen.Außerdem unterscheiden sich Sammelbegriffe häufig von der Singularversion.


--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Dies sind die Konventionen, die mir beigebracht wurden, aber Sie sollten sich an die von Ihnen verwendeten Entwicklungsschläuche anpassen.

Plural.Es handelt sich um eine Sammlung von Entitäten.
Ja.Das Attribut ist eine Darstellung einer einzelnen Eigenschaft einer Entität.
Ja, der Präfix-Tabellenname ermöglicht eine leicht nachverfolgbare Benennung aller Einschränkungsindizes und Tabellenaliase.
Pascal-Schreibweise für Tabellen- und Spaltennamen, Präfix + Großbuchstaben für Indizes und Einschränkungen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow