Hi Folks !

Ich muss euch mal etwas zu dem Thema Tabellenaliasnamen in SQL fragen. Ein Arbeitskollege von mir meinte heute mal ganz nebenläufig, dass viele Programmierer diese Aliasnamen in ihren SQL Befehlen so nutzen, um so immer allgemeingültige SQL Statements zu formulieren und kein konkretes Tabellenfeld ansprechen zu müssen.

So könne man angeblich ohne weiteres auch mal die komplette Datenbank oder nur einzelne Datenbanktabellen im Hintergrund austauschen und der SQL Befehl würde aufgrund der Aliasnamen immernoch seine vollständige Gültigkeit behalten. Der SQL Befhel wäre also somit volständig von der Datenebene bzw. Datenbank entkoppelt.

Ist das so korrekt und funktioniert so etwas wirklich? Für mich ist das etwas schwer vorstellbar, könnte mir vielleicht jemand dazu ein simples Praxisbeispiel aufzeigen?

Ich möchte mich schon einmal für die Antworten und damit verbundene Hilfestellung bedanken.

Greetz
Felix

Hallo nochmal !

Och hoffe, dass mir hier jemand weiterhelfen kann wegen meiner Frage.

Ich schätze mal, es ist so etwas gemeint wie dem Definieren einer Funktion, der evtl. dann die Tabellenbezeichnungen als Parameter mitübergeben werden und in der Funktion in QL Statements eingesetzt werden, die in einer Stringvariable abgelgt sind und als clientseitiger Cursor ausgeführt werden können.

In Abhängigkeit von den Datenbanktabellen (welche evtl. dynamisch ausgelesen werden), werden die Namen dieser Tabellen dann an entsprechende Funktionen übergeben.

Das ist aber von mir auch nur pure Raterei !

Gruß

Deinen 2.ten Post verstehe ich nicht wirklich. Zur ursprünglichen Frage ein Alias ist genau das was der Name sagt ein Alias. Heißt ich brauche den ursprünglichen Tabellennamen nicht mehrmals erwähnen sondern kann auf einen eher kurzen einfachen Namen (Alias) zurückgreifen.

Das mit dem Austauschen ist eher eine theoretische Möglichkeit. Wenn ich mehrere Tabellen mit gleicher Struktur habe die ich einfach gegeneinander austauschen könnte denke ich eher an ein schlechtes Datenbankdesign als ein Feature. Ebenso an dein Gedankenspiel von dynamischen SQL. Das ist kein Feature das man innerhalb von T-SQL in Stored Procs, Stored Functions, Triggern etc einsetzen sollte. Das geht maximal als Notlösung durch wenn ein mäßiges DB Design anders nicht zu retten ist.