Datenbank-, Tabellen- und Spaltenbenennungskonventionen?

Question

Wenn ich eine Datenbank entwerfe, frage ich mich immer, ob es einen besten Weg gibt, ein Element in meiner Datenbank zu benennen. Oft stelle ich mir die folgenden Fragen:

1. Sollten Tabellennamen im Plural stehen?
2. Sollten Spaltennamen Singular sein?
3. Soll ich Tabellen oder Spalten vorangestellt werden?
4. Sollte ich bei der Benennung von Artikeln Groß- und Kleinschreibung verwenden?

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

Answer 1

Ich höre immer wieder das Argument, dass es nur eine Frage des persönlichen Geschmacks ist, ob eine Tabelle im Plural geschrieben wird oder nicht, und dass es keine beste Praxis gibt. Ich glaube nicht, dass das stimmt, vor allem nicht als Programmierer und nicht als DBA. Soweit ich weiß, gibt es keine legitimen Gründe, einen Tabellennamen zu pluralisieren, außer "Es macht einfach Sinn für mich, weil es eine Sammlung von Objekten ist", während es legitime Vorteile im Code gibt, wenn Tabellennamen in der Einzahl verwendet werden. Zum Beispiel:

1. Es vermeidet Fehler und Irrtümer, die durch Mehrdeutigkeiten im Plural verursacht werden. Programmierer sind nicht gerade für ihre Rechtschreibkenntnisse bekannt, und die Pluralisierung einiger Wörter ist verwirrend. Endet das Wort im Plural zum Beispiel auf 'es' oder nur auf 's'? Heißt es Personen oder Menschen? Wenn Sie an einem Projekt mit großen Teams arbeiten, kann dies zu einem Problem werden. Ein Beispiel: Ein Teammitglied verwendet die falsche Methode, um eine von ihm erstellte Tabelle zu pluralisieren. Wenn ich mich mit dieser Tabelle befasse, wird sie bereits überall im Code verwendet, auf den ich keinen Zugriff habe oder dessen Korrektur zu lange dauern würde. Das Ergebnis ist, dass ich jedes Mal, wenn ich die Tabelle verwende, daran denken muss, sie falsch zu schreiben. Mir ist etwas sehr Ähnliches passiert. Je einfacher es für jedes Teammitglied ist, die exakten, korrekten Tabellennamen durchgängig und einfach zu verwenden, ohne Fehler zu machen oder die Tabellennamen immer wieder nachschlagen zu müssen, desto besser. Die Singularversion ist in einer Teamumgebung viel einfacher zu handhaben.

2. Wenn Sie die Singularversion eines Tabellennamens verwenden UND dem Primärschlüssel den Tabellennamen voranstellen, haben Sie nun den Vorteil, dass Sie den Tabellennamen leicht aus dem Primärschlüssel ableiten können oder umgekehrt, und zwar allein durch Code. Man kann eine Variable mit einem Tabellennamen erhalten, "Id" an das Ende anhängen, und schon hat man den Primärschlüssel der Tabelle per Code, ohne eine zusätzliche Abfrage machen zu müssen. Oder Sie können "Id" am Ende eines Primärschlüssels abschneiden, um einen Tabellennamen per Code zu ermitteln. Wenn Sie "id" ohne einen Tabellennamen für den Primärschlüssel verwenden, können Sie den Tabellennamen nicht über Code aus dem Primärschlüssel ermitteln. Außerdem verwenden die meisten Leute, die Tabellennamen pluralisieren und PK-Spalten den Tabellennamen voranstellen, die Singularversion des Tabellennamens in der PK (z. B. statuses und status_id), was es unmöglich macht, dies überhaupt zu tun.

3. Wenn Sie die Tabellennamen in Singular setzen, können Sie sie mit den Klassennamen übereinstimmen lassen, die sie repräsentieren. Auch dies kann den Code vereinfachen und ermöglicht es Ihnen, wirklich tolle Dinge zu tun, wie z. B. eine Klasse zu instanziieren, indem Sie nichts anderes als den Tabellennamen verwenden. Es macht Ihren Code auch einfach konsistenter, was zu...

4. Wenn Sie den Tabellennamen einzigartig machen, wird Ihr Benennungsschema konsistent, organisiert und leicht an jedem Ort zu pflegen. Sie wissen, dass es sich in jeder Instanz Ihres Codes, sei es in einem Spaltennamen, als Klassenname oder als Tabellenname, um denselben exakten Namen handelt. So können Sie globale Suchvorgänge durchführen, um zu sehen, wo diese Daten überall verwendet werden. Wenn Sie einen Tabellennamen pluralisieren, wird es Fälle geben, in denen Sie die Singularversion dieses Tabellennamens verwenden (die Klasse, in die er sich verwandelt, im Primärschlüssel). Es ist einfach sinnvoll, dass Ihre Daten nicht in einigen Fällen im Plural und in anderen Fällen im Singular verwendet werden.

Zusammenfassend lässt sich sagen, dass Sie, wenn Sie Ihre Tabellennamen pluralisieren, alle möglichen Vorteile verlieren, die Ihren Code intelligenter und einfacher zu handhaben machen. Es kann sogar Fälle geben, in denen Sie Nachschlagetabellen/Arrays haben müssen, um Ihre Tabellennamen in Objekt- oder lokale Codenamen umzuwandeln, was Sie hätten vermeiden können. Singuläre Tabellennamen, auch wenn sie sich anfangs vielleicht ein wenig seltsam anfühlen, bieten erhebliche Vorteile gegenüber pluralisierten Namen und sind meiner Meinung nach die beste Vorgehensweise.

Answer 2

Ich bin auch für eine Benennungskonvention im Stil von ISO/IEC 11179, wobei ich anmerken möchte, dass es sich dabei eher um Leitlinien als um Vorschriften handelt.

Ver Datenelementname auf Wikipedia :

"Tabellen sind Sammlungen von Entitäten und folgen den Richtlinien für die Benennung von Sammlungen. Idealerweise wird ein Sammelname verwendet: z. B. Personal. Der Plural ist ebenfalls korrekt: Mitarbeiter. Falsche Namen sind unter anderem: Employee, tblEmployee und EmployeeTable."

Wie immer gibt es Ausnahmen von den Regeln, z.B. kann eine Tabelle, die immer genau eine Zeile hat, besser einen singulären Namen haben, z.B. eine Konfigurationstabelle. Und Konsistenz ist von größter Wichtigkeit: Prüfen Sie, ob es in Ihrem Unternehmen eine Konvention gibt, und wenn ja, halten Sie sich daran; wenn sie Ihnen nicht gefällt, machen Sie einen Business Case, um die Konvention zu ändern, anstatt ein Einzelkämpfer zu sein.

Answer 3

Unsere Präferenz:

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

   Update person set property = 'value' wirkt auf jede Person in der Tabelle.
   Select * from person where person.name = 'Greg' gibt eine Sammlung/Reihenfolge von Personenzeilen zurück.

2. Sollten Spaltennamen Singular sein?
   Normalerweise ja, es sei denn, Sie verstoßen gegen die Normalisierungsregeln.

3. Soll ich Tabellen oder Spalten vorangestellt werden?
   Meistens eine Plattformpräferenz. Wir ziehen es vor, Spalten mit dem Tabellennamen voranzustellen. Wir präfixieren keine Tabellen, aber wir präfixieren Views (v_) und Stored_procedures (sp_ oder f_ (function)). Das hilft Leuten, die versuchen wollen, v_person.age zu aktualisieren, das eigentlich ein berechnetes Feld in einer Ansicht ist (die sowieso nicht aktualisiert werden kann).

   Es ist auch eine gute Möglichkeit, eine Schlüsselwortkollision zu vermeiden (delivery.from bricht, delivery_from aber nicht).

   Das macht den Code zwar ausführlicher, trägt aber oft zur besseren Lesbarkeit bei.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... ist sehr lesbar und eindeutig. Das kann allerdings aus dem Ruder laufen:

   customer.customer_customer_type_id

   zeigt eine Beziehung zwischen customer und der Tabelle customer_type an, gibt den Primärschlüssel der Tabelle customer_type an (customer_type_id), und wenn Sie beim Debuggen einer Abfrage jemals 'customer_customer_type_id' sehen, wissen Sie sofort, woher sie stammt (Tabelle customer).

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

   customer_category_customer_type_id

   ... ist ein wenig (!) zu lang geraten.

4. Sollte ich bei der Benennung von Artikeln Groß- und Kleinschreibung verwenden? Ja - Kleinschreibung :), mit Unterstrichen. Diese sind sehr gut lesbar und plattformübergreifend. Zusammen mit 3 oben macht es auch Sinn.

   Das meiste davon sind jedoch Vorlieben. - Solange Sie konsequent sind, sollte es für jeden, der es lesen muss, vorhersehbar sein.

Answer 4

Ich weiß, dass ich spät dran bin und die Frage bereits sehr gut beantwortet wurde, aber ich möchte meine Meinung zu Nr. 3 bezüglich der Voranstellung 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.

Nehmen wir z. B. die Tabellen "customer" und "address" und verwenden wir die Präfixe "cust" bzw. "addr". Die Tabelle "customer" würde "cust_id", "cust_name" usw. enthalten. "address" würde "addr_id", "addr_cust_id" (FK zurück zum Kunden), "addr_street", etc. enthalten.

Als ich zum ersten Mal mit dieser Norm konfrontiert wurde, war ich strikt dagegen; ich hasste die Idee. Ich konnte die Vorstellung von all der zusätzlichen Tipparbeit und Redundanz nicht ertragen. Jetzt habe ich genug Erfahrung damit gemacht, um nie wieder zurückzukehren.

Dies hat zur Folge, dass alle Spalten in Ihrem Datenbankschema eindeutig sind. Es gibt einen großen Vorteil, der alle Argumente übertrumpft, die dagegen sprechen (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 Nutzen von Nr. 1 ist unglaublich groß. Ich kann eine Spalte veralten lassen 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 umstrukturiert werden muss. Oder ich kann einfach feststellen, ob Daten aus einer Spalte überhaupt in einem bestimmten Teil des Systems verwendet werden. Ich kann gar nicht zählen, wie oft sich dadurch ein potenziell riesiges Projekt in ein einfaches verwandelt hat, und wie viele Stunden wir bei der Entwicklung eingespart haben.

Ein weiterer, relativ unbedeutender Vorteil ist, dass Sie Tabellen-Aliase nur verwenden müssen, wenn Sie einen Self-Join durchführen:

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%';

Answer 5

Werfen Sie einen Blick auf ISO 11179-5: Grundsätze der Benennung und Identifizierung Sie können es hier erhalten: http://metadata-standards.org/11179/#11179-5

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