Eure Namenskonventionen für Tabellen und Attribute

S

saerdna

Fleissiger Benutzer
Beiträge
63
Ich lese gerade etwas zu Namenskonventionen.

Da scheint es etliche Geschmacksnoten zu geben.

Ich greife mal die typischen Kontroversen heraus.

1 Nur Kleinbuchstaben für Tabellen und Attribute?

2 Präfix "tbl_" für Tabellen?

3 Attributnamen mit Kurzform des Tabellennamens (Alias?) als Präfix?
Beispiel:
Tabelle: personen
Tabelen-Alias: pers
Attribut: pers_nachname
Als Argument las ich, dass die Entwicklungsumgebungen für Datenbänker,
was Debugging anginge weit rudimentärer seien als für
Programmiersprachen. Daher die Gesprächigkeit.

4 Auch den Primary Key mit Präfix?
"pers_id" statt "id"?

5 Foreign Key mit Präfix "fk_"?

Was schmeckt euch?

Falls ihr einen guten Artikel kennt, der Vor- und Nachteile der typischen kontroversen Bestandteile von Namenskonventionen abhandelt: yummi.
 
Werbung:
6 Wenn kein Surrogatschlüssel als Primary Key verwendet werden möchte, wird dann "_id" als suffix an den entsprechenden Candidate Key angehängt?
pers_mail_id
 
Das "tbl_" Präfix ist meiner Meinung nach kompletter Blödsinn.

Hier gibt es eine gute Diskussion dazu: Is adding the ‘tbl’ prefix to table names really a problem?

Ich bin außerdem ein Verfechter des Singular für Tabellenname. Eine Eintität einer Datenbank reflektiert (mehr oder weniger) ein reales "Ding". Deswegen sollte die Entität (und damit die Tabelle) "Person" heißen, nicht "Personen"

Letztendlich ist es aber wie mit allen Konventionen: das ist sehr stark Geschmacksfrage. Einigt euch in eurem Team auf einen Satz von Regeln und haltet euch dran. Das ist viel wichtiger.
 
wir hatten eine ähnlich Anfrage kürzlich...

We actually don't have any internal guidelines as it goes in programming taste to go one way or the other. In general, with postgres it doesn't make any sense to use CamelCase style as all capital letters will be lowered (unless you quote the names, which means quoting everywhere, and that's cumbersome). Besides that, and not using reserved names (the ones from the link you pasted above), the rest is up to the developer.

Es gibt auch noch dies: Learning PostgreSQL 10 - Second Edition , das habe ich mir aber nicht angeschaut.
 
@akretschmer
Prima, dann ist ja schonmal einer der Punkte (Kleinbuchstaben) geklärt.

Das von Dir verlinkte Buch liegt hinter einer Bezahlschranke des Verlages. Man kann also nicht ohne Weiteres reinschauen.

Zur Verwendung von Präfixen und Suffixen muss ich mir noch eine Meinung bilden.

Verwendest Du selber welche (siehe die Fragen im Ausgangsposting)?
 
Ich halte es ähnlich, eigene Regeln und daran halten. Ein System ist wichtig für die Übersicht. Bei unserem DMS hat man sich gedacht alle Spalten in allen Tabellen sollten besser unterschiedlich heißen (also auch die IDs), dann braucht man keinen Alias, ganz toll sag ich nur.

Es gibt bei mir nur eine DB die ich von den Konventionen her völlig nach meinem eigenen Ermessen gestalten kann und wo ich das auch durchziehe, ein CRM.

Für mich steht wenig Schreibarbeit im Vordergrund, daher habe ich alle Entitätsnamen auf 3 Buchstaben eingekürzt. Also aus Tabelle Personen wird per, aus Beziehungen zwischen Personen wird z_per_per. tbl_ spare ich mir wobei ich sagen muss es gab Situationen da hätte ich gerne für eine view den selben Namen vergeben wie für eine Tabelle, einen sinnvolleren Namen gab es für die View nicht. Kann man also machen, ich mache es aber nicht.

Ich schreibe alle Spalten- und Tabellennamen klein (sofern ich sie selbst gewählt habe) und den SQL Code groß. Das geht für mich am schnellsten und ich finde es übersichtlich. Ich mache auch viele Zeilenumbrüche und nutze Tabs. ID verwende ich gar nicht als Begriff weil viele ich tatsächlich öfter Attribute habe die IDs anderer Systeme tragen, also z.B. USt-ID. In einigen Tabellen verwende ich zu dem eine sprechende ID (Integer) für die User, in der DB selbst arbeite ich aber immer mit pk und fk_tabellenname als Spalten. Alle PKs und FKs heißen nach möglichkeit gleich so kann ich viel Code einfach kopieren, Aliase verwende ich sowieso konstant wenn mehrere Tabellen im Spiel sind.

Das wichtigeste zum Schluss: Kein Produktivsystem das wir hier im Einsatz haben (Ausnahme das besagte CRM) verwendet tatsächlich Foreign Key Constraints in der DB. Die setzen das alles über Programmlogik um. Ich finde das schadet der Übersicht am meisten, so sind logische Zusammenhänge teilweise nicht auffindbar.
 
Vielen Dank erstmal für Deine Antwort :)

Mir geht es hier im Thread vor allem um die Kontroversen bei Namenskonventionen.

Die Punkte, die weitgehend Konsens (wie z.B. „welche Konvention man verwendet ist weniger wichtig als dass man überhaupt eine verwendet - also Konsistenz“) sind, wollte ich hier gar nicht ausbreiten.

Wenn ich Dich richtig verstehe, lautet Deine Antwort auf 2 und 3 „Nein“.

Du verwendest also weder tbl_ als Präfix in Tabellen und auch nicht <tabellenkurzname>_ als Präfix in Spaltennamen, richtig?

Deine Praxis den PK statt mit „id“ als „pk“ zu bezeichnen gefällt mir.
Aber Deine Aussagen sind noch interpretierbar.

Wenn Du also den Candidate Key „ust_id“ hast und diesen als PK verwenden möchtest, bezeichnest du dann die spalte als „pk_ust_id“ oder nur „pk“? Falls Letzteres der Fall ist, würde ja eine sprechende Bezeichnung fehlen.
Falls Du doch einmal einen Surrogat Key einsetzen musst, mangels CK, bezeichnest Du ihn dann auch als „pk“?
 
saerdna schrieb:
@akretschmer
Prima, dann ist ja schonmal einer der Punkte (Kleinbuchstaben) geklärt.
Zum Vergrößern anklicken....
Bitte.

Das von Dir verlinkte Buch liegt hinter einer Bezahlschranke des Verlages. Man kann also nicht ohne Weiteres reinschauen.
Zum Vergrößern anklicken....
i know.

Zur Verwendung von Präfixen und Suffixen muss ich mir noch eine Meinung bilden.
Verwendest Du selber welche (siehe die Fragen im Ausgangsposting)?
Zum Vergrößern anklicken....

Nein, ich code auch nicht.
 
Zur Frage "Singular oder Plural" überzeugte mich das Plädoyer für Singular in [Sql] Tabellennamensdilemma: Singular vs. Plural Namen sql-server naming-conventions | CODE Q&A [Deutsch]

Dann kann ich meine aktuell offenen Punkte aktualisieren.
Ich möchte noch die Motive der Befürworter/Gegner der jeweiligen Varianten verstehen.

1 [Tabellen] Kennzeichnung: ja oder nein?
Falls ja:
a welches Kürzel?
b als Präfix oder als Suffix?

2 [Spalten] Kennzeichnung als einer Tabelle zugehörig: ja oder nein?
Falls ja:
a Welches Kürzel? Tabellenkurzname? Wo bzw. wie ordnet man ihn dem langen Namen am besten zu?
b als Präfix oder als Suffix?

3 [Spalten] Kennzeichnung als FK: ja oder nein?
Falls ja:
"fk" als Präfix oder als Suffix?

4 [Spalten] Kennzeichnung als PK:
a "pk" oder "id"?
b als Präfix oder als Suffix?

5 [Tabellen] Kennzeichnung bei Viele-zu-Viele-Relation: ja oder nein?
"maps" als Präfix oder als Suffix?

Weitere werden sicher noch dazukommen, wenn ich mal ein bißchen SQL
beherrsche.

Vermutlich hätte ich diesen Thread eher im allgemeinen Forum veröffentlichen sollen, da passt es besser als hier.
Falls ein Admin mitliest und es nicht zuviel Mühe macht, kann der Thread gerne verschoben werden.
 
Werbung:
Gestern erhielt ich einem anderen Thread einen Hinweis auf diese Beispieldatenbank:
PostgreSQL Sample Database

Ich habe sie mir unter verschiedenen Gesichtspunkten angesehen, natürlich auch das Namensmuster.

Noch suche ich ja nach Argumenten für meine persönliche Richtlinien für/gegen Kennzeichnungen in Namen.
Naheliegend fände ich einen Umgang mit Attributnamen, wo man die Zugehörigkeit von FKs durch eine Art "Verlinkung", einen "Bezug"
kennzeichnet. Aber das ist offenbar in der Spezifikation nicht vorgesehen.

Beispiel:

staff (id, first_name, ...)
payment (id, [staff]id, amount, ...)
rental (id, [staff]id, rental_date, ...)

Eine solche Standardisierung würde die Notwendigkeit, FKs in anderer
Weise zu kennzeichnen, überflüssig machen.

Könnt ihr meinen Gedanken nachvollziehen oder ist das "Quatsch von einem Anfänger"?
 
Zurück
Oben