Benennung von Spalten und Tabellen in der Praxis

[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 von Sir Rufo:

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 von Furtbichler:

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 von jobo:

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).