nntp2http.com
Posting
Suche
Optionen
Hilfe & Kontakt

Eure Namenskonventionen fuer Tabellen und Felder

Von: Andreas Borutta (borumat@gmx.de) [Profil]
Datum: 19.06.2009 11:56
Message-ID: <3ki6bifgx4s5$.dlg@borumat.de>
Followup-to: de.comp.datenbanken.misc
Newsgroup: de.comp.datenbanken.mysql de.comp.datenbanken.misc
Hallo,

ich steige gerade ein in's Thema relationale Datenbanken im
Allgemeinen und MySQL im Besonderen.

Über Erfahrung mit DB oder im Programmieren verfüge ich bisher nicht.

Für mich ist bei einem Einstieg in ein Gebiet Klarheit bei Namen
wichtig. Gibt es da Inkonsistenzen, Redundanzen etc., fällt mir das
Lernen deutlich schwerer.

Natürlich ist mir klar, dass es keine /richtige/ Namenskonvention gibt
und dass das Wichtigste ist, eine einmal gewählte konsistent
durchzuhalten.

Ich möchte es vermeiden, als Anfänger 30 Namenskonventionen
auszuprobieren. Lieber wären mir ein paar weniger ;)

Daher bitte ich Euch Erfahrenen darum, hier ein paar Kommentare zu
geben, was sich für Euch bewährt hat.
Hilfreich wären ein paar kurze Infos zu Zusammenhängen/Gründen.

Bitte warnt mich vor aus Eurer Sicht schlechten Konventionen.

Mir geht es zunächst allein um Namenskonventionen für Tabellen und
Felder.

Hier einige Überlegungen/Empfindungen von mir:

* Verbotene Zeichen

[ ] . ! - / SPACE

* Verbotene Zeichenfolgen

Zeichenfolgen, die in der Namenskonvention z.b. für Metainformationen
(Beispiel "_pk" für Primärschlüssel) festgelegt sind, dürfen
keinen
Namensteil bilden.

* Verständlichkeit vor Kürze von Feldnamen

Die Wartbarkeit wird erleichtert, wenn ein Feldname spricht. Eine
Kürzung des Namens, die das einfache Erfassen der Bedeutung stark
behindert, wird vermieden

* Singular für Feldnamen

Es gibt jeweils einen Wert in einem Feld. Da liegt die Konvention
nahe, Feldnamen stets im Singular zu schreiben

* Plural für Tabellennamen

Sie enthalten stets mehrere Datensätze. Da liegt es nahe, sie stets im
Plural zu schreiben

* Gliederung von Namen

Meine Augen tun sich schwer mit der Lesbarkeit der Pascalschreibweise,
wo auch zwischen Namensteilen kein Unterstrich steht.
Wenn man jedoch einen Unterstrich einsetzt, kann man auch gleich auf
die Majuskeln in Namen verzichten. Zumindest sehe ich noch nix, was
dagegen spräche.

* Metainformation Typ: Tabelle oder Feld

Die Praxis des Autors Lorenz Hölscher vor Tabellennamen ein Präfix
"tbl" zu setzen, erschwert, finde ich, die Lesbarkeit.
Vielleicht ist es eine nützliche Alternative, wenn man für
Tabellennamen festlegt, dass sie stets aus drei Großbuchstaben
bestehen?
Dann dürften drei aufeinanderfolgende Großbuchstaben nirgendwo sonst
vorkommen. Also weder als Feldname, noch als Feldnamensteil, noch als
Metainformation, noch als Präfix oder Postfix.
Sonst wäre es wieder Essig mit der Eindeutigkeit, ob ein Name ein
Tabellenname oder ein Feldname ist.
Wenn man Feldnamen stets in Kleinbuchstaben setzt, wäre die
Unterscheidung zu Tabellennamen klar.
Achtung: Teile des Feldnamens

* Anzahl der Metainformationen

Vorbehalte hege ich gegen das Anhängen sehr vieler Postfixe.
Es erschwert die Lesbarkeit.
Braucht man den Datentyp wirklich im Namen? Verhindert er wirklich
sehr oft Fehler bei SQL-Anweisungen?
Da erhoffe ich mir eher, dass ein guter SQL-Editor einen mit
Warnhinweisen versorgt, wenn man versucht zwei Objekte zu
"verknüpfen", wo deren Datentyp dies verbietet.

* Metainformation als Sonderzeichen

Kürzel, die aus Buchstaben bestehen, wie z.B. "Ref", welches Hölscher
zur Kennzeichnung von Fremdschlüsseln einsetzt empfinde ich als
weniger schön, als ein Kürzel aus einem Sonderzeichen.
Warum? Weil sie aussehen wie ein Name/Namensteil.
Aber ich kann nicht einschätzen, welche Probleme man sich einhandeln
würde, wenn man ausgewählte Sonderzeichen als Kennzeichner stattdessen
verwenden würde.

* Metainformation Primärschlüssel

Das Kennzeichnen von Feldnamen, die Primärschlüssel sind, erscheint
mir als nützlich. Nur wie am besten?
Als Postfix "_pk"? Oder lieber als Präfix? Dann aber als erstes hinter
den Präfixen für die Zugehörigkeit zu einer Tabelle?

* Metainformation Fremdschlüssel

Wenn man Feldnamen datenbankweit eindeutig kennzeichnet, indem man
ihnen den Tabellenamen als Präfix voranstellt, dann könnte man die
Information "Dies ist ein Fremschlüssel", allein durch die Existenz
von zwei Präfixen kennzeichnen.
Oder doch "_fk" als Postfix.

* Metainformation Akronym

Ob ein Feldname ein Akronym ist, wie z.B. PLZ, oder ein normaler Name,
könnte man kennzeichnen. Zum Beispiel durch Majuskeln. Aber das beißt
sich mit der Verwendung von Majuskeln zur Unterscheidung von
Tabellennamen und Feldnamen.
Ich finde die Information "Dieser Namensteil ist ein Akronym" nicht
besonders wichtig. Daher: Akronyme als Namensteil von Feldnamen
einfach klein, wie alle anderen Namenteile auch.

* Metainformation Künstlicher Schlüssel

Es gibt sprechende, natürliche Schlüssel. Manche sind
Schlüsselkandidaten.
Möglicherweise sind sie länglich und man wünscht sich daher einen
kurzen, ressourchesparenden künstlichen Schlüsselkandidaten
(Surrogatschlüssel).
Soll seine Künstlichkeit gekennzeichnet werden, zum Beispiel durch
"id"?

* Datenbankweite Eindeutigkeit von Feldnamen

Hölscher gewährleistet dies, indem er vor jeden Namen das Kürzel des
Tabellennamens stellt, als Präfix also.
Sein Motiv: man erspart sich beim eindeutigen Referenzieren die Angabe
eines langen vorangestellten Tabellennamens mit dem Punkt dahinter.
Der Lesbarkeit der Namen schadet diese Praxis.
Aber leider scheidet es als Alternative aus, den Feldnamen eines
Fremdschlüssels so anzugeben:
PRI.number_fk
Also sozusagen im Feldnamen auf eine Tabelle zu referenzieren.
Also führt wohl kein Weg an Hölschers Praxis vorbei.

* Sprache

Englischsprachig. So gibt es keine Probleme, wenn einmal kollaborativ
mit einer international zusammengesetzten Gruppe an der DB gearbeitet
wird

* Standardisierung

Gibt es eine Liste von international typischerweise verwendeten Namen?
Hier meine ich nicht die Namen für Metainformationen, sondern für
Inhalte.


Am Ende ein Beispiel, wo einige der hier erwähnten möglichen
Konventionen angewandt wurden:


Tabellenname (PERSONS): PER
Feldname (Primärschlüssel): PER_id_pk
Feldname: PER_first_name
Feldname: PER_last_name
Feldname (Fremdschlüssel): PER_PRI_number_pk


Tabellenname (PRIORITIES): PRI
Feldname (Primärschlüssel): PRI_number_pk
Feldname: PRI_name



Bestimmt fehlen noch diverse Aspekte zu einer guten Konvention. Ich
freue mich über Eure Anregungen.


Andreas

fup2 de.comp.datenbanken.misc
--
http://borumat.de

[ Auf dieses Posting antworten ]

Antworten