gleichen Namen Spalten in einem Join Vermeiden Auswahl

Question

TABLE_A: columns id, colA1, colA2, ... 
TABLE_B: columns id, colB1, colB2, ... 

QUERY1: SELECT * 
      FROM TABLE_A, TABLE_B 
      WHERE TABLE_A.id = TABLE_B.id 
-- This works perfectly 

QUERY2: SELECT * 
      INTO #tempT 
      FROM TABLE_A, TABLE_B 
      WHERE TABLE_A.id = TABLE_B.id 
-- This fails because A.id and B.id have same column name in SELECT 
-- ERROR: Column names in each table must be unique. 

Ein offensichtlicher Weg, um das Problem mit Abfrage # 2 der Befestigung ist es, alle Nicht-ID-Spalten von Table_B explizit auszuwählen:

QUERY3: SELECT TABLE_A.*, TABLE_B.colB1, TABLE_B.colB2, ... 

Das Problem mit diesem Ansatz ein allgemeines Problem mit Hartcodierung genaue Liste der Spalten in eine SELECT-Abfrage ist 2-fach, und ist wirklich:

1. Hartcodierung der Spalten den Code spröde gegen Tabellen macht, die später mehr Spalten hinzugefügt haben. Jedes Mal, wenn Sie TABLE_B eine Spalte hinzufügen, müssen Sie den Code mit der angegebenen Abfrage ändern, erneut testen und erneut freigeben.

2. Wenn es eine Menge von Spalten in einer Tabelle ist, sieht die Abfrage schrecklich und ist schwer durch zu lange SELECT-Anweisung

Gibt es eine Sybase SQL spezifische Lösung für mein Problem zu lesen mit Abfrage # 2, die das Problem mit Abfrage # 3 vermeidet?

Ich bin auf der Suche nach einer Lösung mit Sybase SQL. NICHT anwendbar: Lösungen, bei denen der Anwendungscode verwendet wird, um die Tabellenstruktur zu lesen und die obige Abfrage 3 zu konstruieren. Auch Lösungen mit eval in-Sybase.

Answer 1

Kurze Antwort: NO.

Lange Antwort:

Du wirst es nicht mögen, aber die Antwort ist nicht * zu verwenden, wenn Sie eine Abfrage Authoring.

Angeben, welche Spalten ausgewählt werden sollen, ist ideal, wenn Sie Code schreiben, um die Ergebnisse zu verwenden, sodass Sie wissen, welche Spalten Teil des zurückgegebenen Datasets sind. Im Gegensatz zu dem, was Sie gesagt haben, macht das Nicht-Angeben von ausgewählten Spalten die Downstream-Prozesse spröde, da, wenn jemand eine Spalte zur Tabelle hinzufügt, eine unerwartete Spalte in dem resultierenden Datensatz erscheint. Wenn Sie jede Spalte in der Auswahl angeben, funktionieren vorhandene Berichte oder Ansichten immer dann, wenn Sie der Tabelle eine Spalte hinzufügen.

Auch Schlüsselsäulen sind nicht unbedingt die einzigen, die mehrdeutig sind; Wenn Sie zwei Tabellen haben, die ID-codiert sind, aber auch eine Namensspalte (Say, eine Studententabelle und eine Fakultäts-Tabelle) haben, haben Sie auch eine Spaltenmehrdeutigkeit, selbst wenn Sie die ID-Spalte von der Auswahl ausschließen. Diese beiden Spalten könnten jedoch in der Ergebnismenge, die Sie suchen, wichtig sein.

Nicht Sybase SQL-spezifisch, aber MSDN bietet diese Vorsicht über Choosing All Columns:

Wenn eine SELECT in einer Anwendung oder einem Skript verwendet wird, die Logik in Abhängigkeit von der Anzahl der Spalten in der Ergebnismenge hat, ist es besser, um alle Spalten in der Auswahlliste anzugeben, anstatt ein Sternchen anzugeben. Wenn Spalten später zu der Tabelle oder den Sichten hinzugefügt werden, auf die die SELECT-Anweisung verweist, wird die Anwendung von der Änderung abgeschirmt, wenn die Spalten einzeln aufgelistet wurden. Wenn ein Sternchen (*) angegeben wurde, werden die neuen Spalten zu einem Teil der Ergebnismenge und können sich auf die Logik der Anwendung oder des Skripts auswirken. Sie sollten die Verwendung des Sternchens (*) insbesondere für Katalogsichten, dynamische Verwaltungssichten und systemtabellenwertige Funktionen vermeiden. Zukünftige Upgrades und Releases von Microsoft SQL Server können Spalten hinzufügen und die Reihenfolge der Spalten für diese Ansichten und Funktionen ändern. Diese Änderungen können Anwendungen zerstören, die eine bestimmte Reihenfolge und Anzahl von Spalten erwarten.