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 empfehle, sich die Microsoft SQL Server-Beispieldatenbanken anzusehen: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

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

1. Singuläre Namen für Tabellen
2. Singuläre Namen für Spalten
3. Schemaname für Tabellenpräfix (z. B.: Schemaname.Tabellenname)
4. Pascal-Schreibweise (auch bekannt als Kamel-Großbuchstaben)

Answer 2

Die Antwort kommt spät, aber kurz und bündig:

1. Plural der Tabellennamen: Meine Präferenz ist Plural
2. Singuläre Spaltennamen: Ja
3. Tabellen oder Spalten vorangestellt werden:

• Tische : *In der Regel ist es am besten, keine Präfixe zu verwenden.
• Rubriken : Nein.

4. Verwenden Sie bei der Benennung von Elementen eine beliebige Groß- und Kleinschreibung: PascalCase sowohl für Tabellen als auch für Spalten.

Ausarbeitung:

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

• Ihr Name Primärschlüssel unter Verwendung des Formats "[singularOfTableName]ID". Das heißt, ob Ihr Tabellenname Kunde ou Kunden sollte der Primärschlüssel sein KundenID .
• Weiter, Fremdschlü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 definierte Fremdschlüsselbegrenzungen zwar oft wichtig ist, ist eine konsistente Benennung der Fremdschlüssel immer wichtig
• Ihre Datenbank muss Folgendes enthalten interne Konventionen . Auch wenn ich in späteren Abschnitten sehr flexibel sein werde, innerhalb Die Namensgebung einer Datenbank muss sehr konsistent sein. Ob Ihre Tabelle für Kunden nun heißt Kunden ou Kunde ist weniger wichtig als die Tatsache, dass Sie es in der gleichen Datenbank auf die gleiche Weise tun. Und Sie können eine Münze werfen, um zu entscheiden, wie Sie Unterstriche verwenden, aber dann müssen Sie müssen sie weiterhin auf dieselbe Weise verwenden . Wenn du das nicht tust, bist du ein schlechter Mensch, der ein geringes Selbstwertgefühl haben sollte.

(2) Was Sie wahrscheinlich tun sollten.

• Felder, die dieselbe Art von Daten in verschiedenen Tabellen darstellen sollte gleich benannt werden. Sie sollten nicht Zip in einer Tabelle und ZipCode in einer anderen haben.
• 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 komisch aussehen. Auf Unterstriche gehe ich gleich noch ein. (Sie dürfen ALLCAPS nicht mehr wie in den alten Zeiten verwenden. OBNOXIOUSTABLE.ANNOYING_COLUMN war in DB2 vor 20 Jahren in Ordnung, aber jetzt nicht mehr.)
• Kürzen Sie Wörter nicht künstlich ab. Es ist besser, wenn ein Name lang und klar ist als kurz und verwirrend. Ultrakurze Namen sind ein Überbleibsel aus dunkleren, brutaleren Zeiten. Cus_AddRef. Was in aller Welt ist das? Custodial Addressee Reference? Zusätzliche Kundenerstattung? Benutzerdefinierte Adressreferenz?

(3) Was Sie beachten sollten.

• Ich bin wirklich der Meinung, dass man Tabellen im Plural benennen sollte; andere meinen im Singular. Lesen Sie die Argumente an anderer Stelle. Spaltennamen sollten jedoch Singular sein. Selbst wenn Sie Tabellen im Plural benennen, können Tabellen, die Kombinationen anderer Tabellen darstellen, im Singular stehen. Zum Beispiel, wenn Sie eine Werbeaktionen und ein Artikel Tabelle könnte eine Tabelle, die einen Artikel darstellt, der Teil einer Werbeaktion ist, Promotions_Items heißen, aber ich denke, sie könnte auch Promotion_Items heißen (was die Eins-zu-Viel-Beziehung widerspiegelt).
• Verwenden Sie Unterstriche konsequent und für einen bestimmten Zweck. Nur allgemeine Tabellennamen sollten mit PascalCasing klar genug sein; Sie brauchen keine Unterstriche, um Wörter zu trennen. Sparen Sie Unterstriche entweder (a) um eine assoziative Tabelle zu kennzeichnen oder (b) für Präfixe, auf die ich im nächsten Punkt eingehen werde.
• Präfixe sind weder gut noch schlecht. Sie in der Regel ist nicht das Beste. In den ersten ein oder zwei db würde ich nicht empfehlen, Präfixe für die allgemeine thematische Gruppierung von Tabellen zu verwenden. Die Tabellen passen dann nicht mehr so leicht in die Kategorien, und das kann dazu führen, dass sie härter um Tabellen zu finden. Mit etwas Erfahrung können Sie ein Präfixierungsschema planen und anwenden, das mehr nützt als schadet. Ich habe einmal in einer Datenbank gearbeitet, deren Datentabellen mit tbl , Konfigurationstabellen mit ctbl , Ansichten mit vew , proc's sp und udf's fn und ein paar andere; es wurde sorgfältig und konsequent angewandt, so dass es gut funktioniert hat. Präfixe sind nur dann notwendig, wenn Sie wirklich getrennte Lösungen haben, die sich aus irgendeinem Grund in derselben Datenbank befinden; das Voranstellen von Präfixen kann bei der Gruppierung der Tabellen sehr hilfreich sein. Präfixe sind auch für besondere Situationen in Ordnung, z. B. für temporäre Tabellen, die Sie hervorheben möchten.
• Sehr selten (wenn überhaupt) würden Sie sich Spalten vorangestellt werden.

Answer 3

Ok, wenn wir schon mal dabei sind, Meinungen zu äußern:

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. Ich würde also eine Tabelle mit Entitäten "Personen" (oder "Personen", je nachdem, was Ihnen besser gefällt) nennen.

Für diejenigen, die gerne einzelne "Entitätsnamen" in Abfragen sehen, würde ich Tabellen-Aliase verwenden:

SELECT person.Name
FROM People person

Ein bisschen wie LINQs "from person in people select person.Name".

Was 2, 3 und 4 betrifft, stimme ich mit @Lars überein.

Answer 4

Ich arbeite in einem Datenbank-Supportteam mit drei DBAs und wir haben folgende Optionen in Betracht gezogen:

1. Jede Benennungsnorm ist besser als keine Norm.
2. Es gibt keinen "einzig wahren" Standard, wir alle haben unsere Vorlieben
3. Wenn es bereits einen Standard gibt, sollten Sie ihn verwenden. Schaffen Sie keinen neuen Standard und verwässern Sie die bestehenden Standards nicht.

Wir verwenden Singularnamen für Tabellen. Den Tabellen wird in der Regel der Name des Systems (oder sein Akronym) vorangestellt. Dies ist nützlich, wenn das System komplex ist, da Sie das Präfix ändern können, um die Tabellen logisch zusammenzufassen (z. B. reg_customer, reg_booking und regadmin_limits).

Bei Feldern erwarten wir, dass die Feldnamen das Präfix/die Abkürzung der Tabelle enthalten (z. B. cust_address1), und wir bevorzugen auch die Verwendung eines Standardsatzes von Suffixen (_id für die PK, _cd für "Code", _nm für "Name", _nb für "Nummer", _dt für "Datum").

Der Name des Feldes "Fremdschlüssel" sollte derselbe sein wie der des Feldes "Primärschlüssel".

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 an Ihre Entwickler weiterzugeben. Wenn sie dann beschließen, eine neue Tabelle zu erstellen, können sie sich auf das Dokument beziehen, anstatt zu "raten", wie die Tabelle und die Felder heißen sollten.

Answer 5

1. Nein. Eine Tabelle sollte nach der Entität benannt werden, die sie repräsentiert. Person, nicht Personen, ist die Bezeichnung für denjenigen, den einer der Datensätze repräsentiert.
2. Auch hier gilt das Gleiche. Die Spalte Vorname sollte wirklich nicht Vorname heißen. Es hängt alles davon ab, was Sie mit der Spalte darstellen wollen.
3. NEIN.
4. Ja. Der Klarheit wegen. Wenn Sie Spalten wie "Vorname" haben müssen, macht die Großschreibung die Lesbarkeit einfacher.

Okay. Das sind meine $0,02