Tabellen mit Alias-Namen nutzen

[Kampfgummibaerlie]

Ich habe heute in der Schule beigebracht bekommen, dass heutzutage nur der erste Buchstabe vom Tabellennamen als Aliasnamen eingesetzt werden und von diesem selektiert wird.

Beispiel:

create table kunde(kundennummer integer primary key, vorname text, nachname text, geburtstag date);
create table bestellung (bestellnummer integer primary key, kundennummer integer references kunde(kundennummer), produkt text);
insert into kunde values (1, 'Victor', 'MeineWenigkeit', '1991-12-05');
insert into bestellungen values (1, 1, 'Notebook');

Hier eine Abfrage:

select k.vorname, k.nachname, k.geburtstag, b.produkt from kunde k join bestellung b using (kundennummer);

sollte ich mir für die paar zeichen das prinzip angewöhnen oder sollte ich lieber beim ausschreiben der tabellennamen bleiben? hier direkt eine frage an die erfahrenen SQL-Leute: gibt es Datenbanken mit ungemein langen Tabellennamen, dass das sinnvoll wäre?
oder gewöhnt man sich sowas recht einfach an, wenn man eine weile auf diese Art damit arbeitet?

kannte aliasnamen für tabellen bisher nur aus rekursiven Abfragen :X

LG und so, Kampfgummibaerlie

 

[castorp]

Nur einen Buchstaben verwende ich eigentlich nur bei "ad-hoc" Abfragen die nicht dauerhaft (=produktiv) verwendet werden.

Für alles was in Produktion geht, bzw. von mehr als nur mir verwendet (und verstanden) werden soll, nehme ich längere Abkürzungen.

Meistens zwei bis drei Buchstaben. Z.b "knd" für Kunde, oder "bst" für Bestellung. Ich war auch schon in Projekten, in denen wir Standardkürzel (mit 3 Buchstaben) für jede Tabelle definiert hatten, die verpflichtet verwendet werden müssen.

Die Regel immer einen Alias zu verwenden finde ich gut. Bei Abfragen die mehr als eine Tabelle verwenden sind sie immer Empfehlenswert. Bei Abfragen mit Sub-Queries sollten sie Pflicht sein.

Auch das Referenzieren von Spalten mit ihrem Tabellen-Alias halte ich für guten Programmierstil, da man sofort sieht welche Spalte zu welcher Tabelle gehört.

 

[ukulele]

Bei mir ist das sehr unterschiedlich.

In meinem CRM nutze ich 3-Buchstabenkombinationen als Tabellenname, also unt für Unternehmen, per für Person, z_unt_per für Beziehungen zwischen den beiden, etc. Fremdschlüssel heißen dann entsprechend fk_unt und fk_per und der Primary Key pk. In jeder Tabelle entsprechend. Ich kann also ~90% aller Spalten ohne einen Blick in die Tabelle ansprechen, weil klar ist, wie die Spalte heißen müsste. In produktivem Code verwende ich dann Aliase mit einem Buchstaben, das ist meist eindeutig. Es gibt wenig Außnahmen, unt und url sind beides Tabellen mit u ;-)

In vielen anderen DBs bin ich nicht in der Lage, Tabellennamen zu bestimmen. Unser DMS z.B. verwendet in seinem doch recht alten Schema in allen wichtigen Tabellen eindeutige Spaltennamen. Da zeigt dann die parentid aus einer Tabelle und die objectid aus der anderen Tabelle auf die objid als PK... Noch dazu hat ELO jetzt angefangen im Frontend selbst Aliase zu nutzen, da musste ich erstmal viel umschreiben.

Außerdem baue ich an einem ETL System, im wesentlichen für DATEV Daten. Da verwende ich sehr lange Tabellennamen, Originalname + "Verwendungsziel", sonst komme ich viel zu schnell in Konflikte und verliere die Übersicht. Bis zur endgültigen Auswertung bilde ich erstmal alles Flach ab und in der Auswertung wird es häufig sehr komplex und am Ende lande ich dann öfter mal bei t1 bis tN im Xten WITH....