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:
- Der Tabellenname ist ein Wort als Einzahl, also 'Customer' nicht 'Customers'.
- 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.
- 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).
- 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.
- 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
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...