Benennung von Spalten und Tabellen in der Praxis

[Der schöne Günther]

Es mag den Eindruck machen, ich werfe ohne eigene Vorarbeit direkt eine Frage in den Raum. Ich habe fast keine Praxiserfahrung und kenne daher wenig Punkte und Alltagsbegriffe, die man weiterverfolgen kann.

Es geht um folgendes. Ja, "choose short, unambiguous names" und so weiter. Die ganze Theorie, wie man dies und das nennen sollte.

Sieht die Praxis wirklich genauso aus? Oder muss man sich beim Umstieg von z.B. mySQL auf Postgres drauf gefasst machen, dass manche Spalten ihren Namen nicht behalten können? Ich habe dunkel noch die Empfehlung "Nein, nenne die Spalte besser nicht NAME oder ID" im Hinterkopf. War das Quatsch? Oder galt das nur für ein bestimmtes DBMS? :gruebel:

Habt Ihr eigene Einschränkungen entwickelt an die Ihr euch haltet? Aus rein technischer Sicht, keine Style-Guidelines.

[Uwe Raabe]

Jede Datenbank hat sicher den einen oder anderen Namen, der schon für etwas anderes reserviert ist und womöglich jedesmal gequoted werden muss. Bei der Verwendung der meisten Zugriffskomponenten sollte das aber transparent für den Entwickler geschehen. In vielen Fällen kann man auch ein Field-Mapping durchführen.

Bei TClientDataset muss man bei Nested DataSets nur aufpassen, daß die verbundenen Spalten in den beiden Tabellen gleich heißen. Insofern funktioniert die generelle Benennung der AutoInc/UniqueID-Spalte mit "ID" dort schon mal nicht.

[jobo]

Ich arbeite vorwiegend mit Oracle, hier gibt es eine (heutzutage) unerklärliche Einschränkung auf max 32 Zeichen für Objektnamen.

Vielleicht ist das aber auch ein Erfahrungswert, ängere Namen werden wahrscheinlich nicht gelesen, unterschieden und sind im Objektexplorer nicht zu erkennen.

Erfahrungswert ist, dass Tools nicht durchgängig lokalisierte Benennung erlauben, Umlaute, Leerzeichen usw. also am besten nicht verwenden.
Wer sich an geklammerte oder wie auch immer gequotete Feldnamen gewöhnt hat, meinetwegen, ich finde es störend, sogar häßlich, und es hat mglw. wiederum Seiteneffekte (je nach System und Quotezeichen)

Eine Tabelle sollte einen treffenden Namen haben, der sollte irgendwie zur abgebildeten Entität passen und vielleicht auch dann noch passen, wenn die erste Revision gemacht wurde.

Ein Tabellenname könnte auch ein Domänenkürzel als Prefix haben für den groben Überblick (damit Hacker sich besser zurecht finden)

Also Domäns ala 'SYS', 'BASE', 'CUST..'

Feldbenennung:
Ich verwende gern ein z.B. vierstelligen Präfix, der grob gesagt die Großbuchstaben einer CamelCase Notation wiedergäbe, wenn es CamelCase wäre.
Bsp.: CSTR_ID

Damit spiegelt jedes Feld mehr oder weniger die Herkunfts-Tabelle wieder.
Bei Foreign Keys könnte man drüber streiten, ob man den original Namen wiederholt oder z.B. das Standard Präfix davor stellt.
Unterscheiden sich Foreign- und Primary Key Spaltennamen kann man etwas rotzig auch ein "Select * from tab1, tab2, " machen, ohne das gleichnamige Spalten nerven, was ich sehr schön finde.
Spaltennamen sollten m.E. über alle Tabellen hinweg eindeutig sein.

Der Prefix führt automatisch dazu, das Schlüsselwörter idR egal sind. Wer eine Spalte "Group by" nennt, ist aber irgendwie auch selber Schuld.

Als Zeichen nimmt man sicherheitshalber auch heute noch US ASCII 7.

Und noch was ganz anderes:
Egal ob schon alles zu spät ist oder man neu anfängt mit einem Datenmodell.
1. Schritt Tabellen anlegen
2. Schritt View drüber und man hat ein erstes Interface (Namen und Rechte)

Ich bin mir nicht sicher, ob Du das wissen wolltest, aber nun hab ich es geschrieben. :)

[sx2008]

Regel 1: nur Buchstaben, Ziffern und den Unterstrich verwenden (keine Umlaute, Leerzeichen oder Sonderzeichen)
Regel 2: ein Bezeichner darf nicht mit einer Ziffer beginnen
Regel 3: ein Bezeichner darf kein reserviertes Wort des DBMS sein (wie z.B. AND, USER, INDEX, TIME, CHAR, INSERT, ...)
Regel 4: max. 64 Zeichen pro Bezeichner (die Obergrenze lässt sich nicht so scharf definieren; man sollte unterhalb der Genze der meisten DBMS bleiben. Mit max 32 Zeichen ist man auf der sicheren Seite wenn man veraltete DBMS mal ausnimmt)
Regel 5: wie Regel 3 nur sollte man ALLe gängigen DBMS berücksichtigen damit man bei einer Portierung auf ein anderes DBMS nicht in Schwierigkeiten gerät

Im Anhang ist eine Unit mit der man diese Regeln überprüfen kann.

[Der schöne Günther]

Danke für die Hilfe soweit, das hat mir alles gut weitergeholfen :thumb:

[p80286]

Ganz besonders kreativ darfst Du Sein wenn Du Access verwendest "Des schönen Günters erste Tabelle" ist da durchauszulässig. Ob Du dann allerdings über ADO,ODBC,JET.... zugreifen kannst steht auf einem ganz anderen Blatt!
Darum unbedingt die vorgenannten Regeln beherzigen.
Ebenfalls nicht unproblematisch können sein % _ * &. (werden als Wildcards/Escapekeys verwendet!)

Gruß
K-H

[nahpets]

Zitat:

Zitat von Smut (Beitrag 1243078)

'_' ist auch böse??

Nach meiner bisherigen Erfahrung nicht, das einzige Zeichen, außer Buchstaben und Ziffern, dass wir in Tabellen-, Spalten, Funktions-... -namen nutzen.

[Der schöne Günther]

Den Unterstrich habe ich jetzt auch schon so oft gesehen, der höchstwahrscheinlich nirgendwo.

[Furtbichler]

Felder dürfen auch Leerzeilen und '_' beinhalten, nur ob das sinnvoll ist, ist die Frage (und ob das ANSI SQL konform ist, weiß ich auch nicht). Aber wozu? Na, Ich verwende Spalten mit Leerzeichen manchmal in Spaltenüberschriften von Views, damit im Report (meistens eine Direktanbindung von EXCEL an die DB) gleich der richtige Name erscheint: Kunden sind ja diesbezüglich ziemlich penetrant.

Es gibt Nomenklaturen, die mit einem Prefix pro Feldnamen arbeiten: Folgende Regeln habe ich für meine Projekte vor 20 Jahren eingeführt und mach das heute noch so:

1. Der Tabellenname ist ein Wort als Einzahl, also 'Customer' nicht 'Customers'.
2. Jede Tabelle bekommt einen Prefix aus 2 Buchstaben, bei sehr großen Projekten auch drei. Der Prefix soll eine Gedächtnisstütze für den Tabellennamen sein, also z.B. 'cu' bei 'Customer' (aber eben nicht 'xy'), 'pr' für 'Product' etc.
3. Jedem Feld ist der Prefix vorangestellt, somit ist jedes Feld eindeutig innerhalb der DB. Der Name des Kunden ist dann z.B. 'cuName'. Ausnahme: Fremdschlüssel, die heißen so wie die PK-Spalte der referenzierten Tabelle. Wenn es also in der Customer-Tabelle einen Foreign-Key in die Adressen-Tabelle gibt, dann heißt dieser einfach 'adID' (siehe auch nächster Punkt).
4. Jede Tabelle hat einen Primary Key mit einem autogenerierten Wert. Der Name dieser Spalte ist '<Prefix>ID', z.B. 'cuID' für die PK-Spalte der Customer-Tabelle.
5. Die Reihenfolge der Spalten ist: PK,FK,Beschreibungen,Daten,Optionen

Die meisten ORM mit Database-First erlauben es, die Prefixe für die Erstellung der Eigenschaftsnamen wegzuschnippeln, sodaß meine

Delphi-Quellcode:

Customer

-Klasse anständige Propertienamen hat, also 'ID','Name' etc. Der FK wird eh durch den Referenztabellennamen ersetzt.

Bisher habe ich noch kein Projekt mit Code-first angefangen, vermutlich, weil ich mit dem DB-Design großalt geworden bin.

Mit diesen Prefixen kann man auf die explizite Verwendung von Aliasnamen in der Feldliste von Queries verzichten und es erleichtert Joins. So sieht das dann z.B. aus

Code:

Select cuID, cuName, adStreet, adCity
from Customer c 
     join Address a on c.adID = a.adID
where cName like 'Mül%'

Wenn man sich an die Prefixe gewöhnt hat, ist dann so eine Query sehr leicht zu lesen, weil man nicht erst schauen muss, welche Tabelle den den Alias 'c' hat. Ok, man kann auch in allen Queries immer den Alias 'cu' nehmen, aber sagt das mal dem 'Neuen', der zur Einführung neue Reports bauen soll...

[Sir Rufo]

Die Lesbarkeit leidet aber auch nicht bei

SQL-Code:

Select cu.ID, cu.Name, ad.Street, ad.City
from Customer cu
     join Address ad on cu.AddressID = ad.ID
where cu.Name like 'Mül%'

für mich sogar besser lesbar.

Aufwendig ist natürlich das Verbinden von Tabellen mit gleichlautenden Spaltennamen.
Aber schreibfaul sollte man nicht sein und bis zu einem gewissen Grad kann man sich auch ein Tool schreiben, was die Abfragen nach der gewünschten Regel schreibt.

SQL-Code:

Select 
  cu.ID Customer_ID, // oder cuID
  cu.Name Customer_Name, 
  ad.Street Adress_Street, 
  ad.City Address_City
from Customer cu
     join Address ad on cu.AddressID = ad.ID
where cu.Name like 'Mül%'

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1243102)

Die Lesbarkeit leidet aber auch nicht bei...
für mich sogar besser lesbar.

Wenn es nur eine Möglichkeit gäbe, leckeres Essen zuzubereiten, wie langweilig wäre das Leben. Natürlich ist das mindestens genausogut lesbar.

Zitat:

SQL-Code:

Select 
  cu.ID Customer_ID, // oder cuID
  cu.Name Customer_Name, 
  ad.Street Adress_Street, 
  ad.City Address_City
from Customer cu
     join Address ad on cu.AddressID = ad.ID
where cu.Name like 'Mül%'

Mit meiner Nomenklatur brauche aber keine Aliase mehr, wenn ich verknüpfte Abfragen verwende und eindeutig zuordenbare Feldnamen möchte: Zudem kann ich in meiner Anwendung auch eine zentrale Formatierungshilfe schreiben, durch die ich einmalig alle Queries schicke: Sobald die ein 'cuNumber' sehen, wissen sie, das es sich um eine Kundennummer handelt, die bitte als 'D-DDD/DD' formatiert werden soll, das 'prWeight' Gewicht des Produktes hat 2 Nachkommastellen etc.

Ich habe eine TcxEditRepository, die dann den entsprechenden TcxEditRepositoryItem an das Steuerelement/GridColumn bindet. Das läuft alles automatisch ab, sodaß die bescheuerte Klickarbeit zum Einstellen der Spaltenformate/breiten/farben usw. so ziemlich komplett entfällt. Das geht natürlich auch mit anderen Nomenklaturen, auch mit deiner Idee (zwar nur, wenn Du mit Aliase verwendest).

Wichtig ist doch nur, das man einen Plan hat, der stringent durchgezogen wird und einem das Lesen und die Arbeit erleichtert. Nichts ist schlimmer als 'Kraut und Rüben' im Code. Mein Ziel war es, die Felder eindeutig zuordenbar zu machen, wie man das macht, ist dann ne andere Geschichte.

Das 'häßliche', nämliche die Prefixe, schnippeln ja die Database-First ORM-Mappingtools ab. Wobei das auch ein riesen Vorteil der Prefixe ist: Sie werden automatisch weggeschnippelt: Offensichtlich ist die Prefixgeschichte weit verbreitet (sonst würden die ORM-Mapper das ja wohl nicht anbieten).

[jobo]

Zitat:

Zitat von Furtbichler (Beitrag 1243126)

Mit meiner Nomenklatur brauche aber keine Aliase mehr, wenn ich verknüpfte Abfragen verwende und eindeutig zuordenbare Feldnamen möchte

Ich nehme an, Du meinst Feldaliase.
Table Aliase sind dennoch hilfreich, wenn das Query Tool Nachschlage Funktion hat.
@Sir Rufo: Table Aliase als Ersatz für Prefixe laufen fast zwangsläufig auf Feld Aliase hinaus, die idR auch noch länger sein müssten als ein 2 oder 3 stelliger Table Alias.

Generierte, erst recht handgeschriebene Feld Aliase bieten Spielraum für nicht eindeutige Feldbezeichnungen, also Verwechselung u.a.
Ich arbeite viel mit Views, die Feldnamen in den Views sind immer identisch mit den Originalfeldnamen der Tabelle, Feld Aliase sind also gar nicht möglich, schemaweit eindeutige Feldnamen dagegen nötig.
Notwendige Ausnahme: virtuelle Spalten (Aggregate, Berechnungen, Text Konkatenierung, ..)
Hier muss natürlich ein Alias verwendet werden, ich nutze meist den Prefix der Kerntabelle, den Namensteil der Kernspalte und einen Suffix, der die Spalte als virtuell kennzeichnet. Ein Spaltennamen-Hinweis auf eine verwendete Aggregatform kann auch nützlich sein.

[Furtbichler]

Zitat:

Zitat von jobo (Beitrag 1243129)

Ich nehme an, Du meinst Feldaliase.

Natürlich.
In den Queries verwende ich natürlich auch zwangsweise Tabellenaliase. Die sind -naheliegend- mit den Feldprefixen identisch. In der Feldliste einer Query verzichte ich dann auf die Angabe der Tabellenaliase, weil es i.a. nicht nötig ist. Außerdem lädt es zum mentalen Stottern ein ;-)

Code:

select cuNumber, adStreet from...
-- vs.
select cu.cuNumber, ad.adStreet from...

Mir fällt gerade noch ein Vorteil 'meiner' Methode ein, insbesondere die Ausnahme, das Fremdschlüssel den Prefix der referenzierenden Tabelle beinhalten. Neben dem sinnlosen Vorteil, das 'NATURAL JOIN's unterstützt würden, wenn sie denn mal eingeführt würden, ist es doch so, das einige Codeproposal Plugins für SSMS einen entsprechenden JOIN gleich vorschlagen:

Code:

select * from Table tb join OtherTable ot on tb.|

Es wird 'tb.otID=ot.otID' vorgeschlagen, auch wenn kein Constraint besteht (ja, Ash on my Head).