Welchem ​​Standard sollte ich beim Benennen von Tabellen und Ansichten folgen?

20

Welchem ​​Standard sollte ich beim Benennen von Tabellen und Ansichten folgen? Ist es zum Beispiel eine gute Idee, so etwas wie tbl_ am Anfang von Tabellennamen zu setzen? Soll ich Code- / Nachschlagetabellen wie ct_, lut_ oder codes_ bezeichnen? Gibt es noch andere Verbote?

Ich benutze MS SQL Server und habe viele Datenbanken mit vielen Tabellen, daher wäre es schön, etwas zu haben, das wir als Standard mit einigen unterstützenden Rationalen verwenden können.

relational-theory  naming-convention 
— Beth Whitezel
quelle

Antworten:

29

OK, zuerst NIEMALS tbl vor den Namen eines Tisches stellen. Es ist ein Tisch, den wir schon jetzt haben. Das nennt man ungarische Notation, und die Leute haben das vor mehr als 5 Jahren eingestellt.

Rufen Sie das Objekt einfach so auf, wie es ist. Wenn eine Tabelle Mitarbeiterdaten enthält, nennen Sie sie "Mitarbeiter". Wenn es Informationen über Computer enthält, nennen Sie es "Computer". Wenn es Computer Mitarbeitern zuordnet, nennen Sie es "EmployeeComputer" oder "ComputerEmployee" (persönlich mag ich "EmployeeComputer" besser).

Es gibt keine richtige Namenskonvention (außer die ungarische Notation nicht zu verwenden). Solange die Objektnamen Sinn machen, ist es wichtig, worauf es ankommt.

— mrdenny
quelle
11
Darüber hinaus sollten Sie die Namen der Tabellen nicht als Nomen im Plural angeben, da ich Beispiele für Employees, Cumputers gesehen habe. Wir alle wissen, dass Tabellen viele Zeilen enthalten sollen, nicht eine.
— Marian
1
Warum würden Sie Ansichten einer Tabelle erstellen? Alles, was eine Ansicht ist, ist eine gespeicherte Select-Anweisung. Die Daten werden nicht hinter einer Ansicht gespeichert, es sei denn, Sie verwenden eine indizierte Ansicht. Ich benutze so ziemlich nie Ansichten, habe nie. Dies hat sicherlich keinen Leistungsvorteil.
— Mrdenny
2
Wir verwenden Ansichten, wenn wir etwas tun möchten, wie ein paar Tabellen zusammenfügen oder Codewerte in vom Menschen lesbare Werte übersetzen. Die zweite Situation ist die, in der Sie einen ähnlichen Namen erhalten würden.
— Beth Whitezel
2
Die Antwort von Mr. Denny und die folgenden Mitwirkenden werden durch Folgendes unterstützt: dba4life.blogspot.com/2007/11/…
1
@Marian: Ich benutze Pluralformen, weil sie die Abfragen natürlicher lesen lassen und Kollisionen mit Schlüsselwörtern lösen. Viele Systeme, mit denen ich gearbeitet habe, hatten eine Auftragsentität. Durch die Verwendung von Pluralformen wird der Tabellenname ordersnicht ordergeändert, und es wird vermieden, dass der Tabellenname bei jedem Benutzer in Anführungszeichen gesetzt werden muss. Dies gilt auch für groupund andere Keywords. Glücklicherweise kollidieren nur wenige Keywords mit gemeinsamen Entitäten.
— BillThor
13

Wir verwenden Schemas (in SQL stellen wir sie uns vielleicht als Namespaces vor) sowohl für Berechtigungen als auch für Gruppierungen. Also statt "tbl" etc haben wir

  • Daten.Thing
  • Data.ThingHistory
  • Data.Stuff

In das Datenschema geht kein Code ein. Außerhalb des Datenschemas befinden sich keine Tabellen. Dies kann natürlich erweitert werden, um ein Lookup- oder Staging-Schema zu haben, wenn Sie dies wünschen.

Für Ansichten, die wir verwenden vw, wurde dies jedoch verwendet, um sie von Tabellen in SQL Server 2000 zu unterscheiden, und es ist jetzt ein bisschen Legacy

— gbn
quelle
3
+1 für die Empfehlung von Schemata. Dies ist praktisch, wenn Sie eine große Datenbank mit Hunderten von Tabellen verwalten. Wir verwenden Schemata für funktionelle zu gruppieren .. wie in Adventureworks hat db
— CoderHawk
5

Persönlich bin ich ein großer Fan der Fanö-Bedingung , was bedeutet, dass kein Name der Anfang eines anderen gültigen Namens sein darf.

Und zweitens ist der Hamming-Abstand zwischen zwei Namen besser als ein Buchstabe.

Ja, das ist die Regel aus vordigitalen Zeiten, aber sie machen das Leben leichter.

Und dritte Namen müssen aussprechbar sein, sonst werden Sie verrückt, wenn die Spracherkennung wahr wird.

— bernd_k
quelle
2
Wenn die Spracherkennung wahr wird, bin ich sowieso verrückt. :-)
— Beth Whitezel
Nur wenn du
— telethon
1
Wenn es zu einer Spracherkennung kommt, werde ich LKW-Fahrer. Das oder ein verrückter Einsiedler.
— Mrdenny
Können Sie (vielleicht anhand eines Beispiels) näher erläutern, was "Fano-Bedingung" ist?
— Nick Chammas
1
@ NickChammas Ich denke in Englisch nennen wir diese Shannon-Fano-Codierung .
— Iain Samuel McLean Elder
2

Ich weiß nicht, dass es da draußen wirklich eine "beste" Namenskonvention gibt, da es wirklich auf die persönlichen Vorlieben und die Leichtigkeit der Entwicklung ankommt. Mein Rat ist, eine Namenskonvention zu wählen und diese einzuhalten. Wenn Sie Wörter mit einem Unterstrich trennen möchten, tun Sie dies in all Ihren Datenbankobjekten. Wenn Sie camelCase verwenden möchten, tun Sie dies in allen Ihren Datenbankobjekten.

In meinem Shop halten wir uns an folgende Regeln:

Wir trennen Wörter mit Unterstrichen und verwenden alle Kleinbuchstaben.
Unsere Tabellennamen beschreiben, was sie sind: dbo.person, dbo.invoice.
Unsere Many-to-Many -Tabellennamen beschreiben auch, was sie sind (mit dem Zusatz mm, um anzugeben, dass eine Many-to-Many-Beziehung abgebildet wird: dbo.person_mm_address. Unsere benutzerdefinierten gespeicherten Prozeduren beschreiben sowohl das Objekt als auch die auszuführende Aktion: usp_person_select , usp_address_select_by_city Unsere Ansichten und Funktionen folgen den gleichen Regeln wie gespeicherte Prozeduren: Unsere Indizes umfassen Tabelle, Schlüsselspalten (in Reihenfolge) und eine Angabe von gruppiert / nicht gruppiert: ix_person_last_name_first_name_nc

Nur weil dies das ist, was wir in meinem Shop verwenden, heißt das nicht, dass diese Regeln für Sie richtig sind. Wählen Sie etwas aus, von dem Sie und Ihr Entwicklungsteam überzeugt sind, dass es nützlich und einfach zu entwickeln ist, und schaffen Sie eine Kultur des Wissens und der Verwendung der von Ihnen festgelegten Namenskonventionen. In unserem Fall umfasst dies die Codeüberprüfung für alle in einer Datenbank erstellten Objekte. Im Laufe der Zeit hat die Kombination aus dokumentierter Namenskonvention und Peer-Code-Überprüfung zu immer weniger Abweichungen von der Konvention geführt.

Ich hoffe, dass diese "Nicht-Antwort" irgendwie hilft.

— Matt M
quelle
2

Damit bin ich seit Jahren zufrieden

  • Tabellennamen: Kapitälchen und Unterstriche, Singular {Kunde, Produkt}
  • Tabellennamen für viele bis viele Beziehungen: Tabellenname1_Tabellenname2: {Kundenprodukt}
  • Aufrufe: Small Caps hinzugefügt v am Ende {customerv, productv, product_groupv}
  • gespeicherte Prozesse: Tabellenname und Funktion {customer_select, customer_insert, customer_delete, customer_update}

Wenn Sie ein günstiges Shared-Hosting-Paket haben, müssen Sie die Projektabkürzung vor allen Ihren Objekten verwenden, z. B. Datenbankadministrator-Site, da_users, da_questions

— Uğur Gümüşhan
quelle
Warum product_groupvund nicht product_group_vfür Ansichten (wenn Sie auf dieser Unterscheidung von Ansichten und Tabellen bestehen)?
— ypercubeᵀᴹ
@ypercube, weil ich zu faul bin, einen zusätzlichen Unterstrich einzugeben, und Tippfehler leicht mache. Ich lese die Wörter leichter, wenn ich einen Unterstrich verwende, und ich verwende v, um die Ansicht von den Tabellen zu trennen, und v ist kein Wort, daher verwende ich keinen Unterstrich. Es sieht inkonsistent aus, ja, aber ich finde dieses Format praktisch.
— Uğur Gümüşhan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.