![]() |
Datenbank: Firebird • Version: 3.0 • Zugriff über: FIREDAC
Firebird 3.0 Order mit Feldname bei Union
Hallo Zusammen,
sorry für den blöden Titel. Ich habe ein Select
Code:
Ich habe in ein SELECT * mit mehreren Tabellen die über Union gebunden sind. Am Ende soll sortiert werden. Bei Union funktioniert, zumindest nach meinem Wissen die Sortierung über Feldnamen nicht. Ich kann jedoch nach Feldnummer gehen ORDER BY 18.
SELECT *
FROM TABLE1 UNION SELECT * FROM TABLE2 ORDER BY 18 Das hat leider ein großen Haken. Wenn ich in den Tabellen Felder hinzufügen würde, könnte sich die FeldNr verschieben und zum falschen Ergebnis führen. Der Feldname wäre hier sicherer. Hat jemand eine Idee? Gruß Kostas |
AW: Firebird 3.0 Order mit Feldname bei Union
SQL-Code:
select * from (
SELECT * FROM TABLE1 UNION SELECT * FROM TABLE2 ) ORDER BY feldname |
AW: Firebird 3.0 Order mit Feldname bei Union
An der Stelle kann man auch sehr schön mit Views arbeiten. (Wie an vielen anderen Stellen auch)
Abgesehen von Aspekten wie Interfacing, diesem Hilfskonstrukt oben und ähnlichen Punkten, bietet ein View bei einem beliebig komplexen Select Statement schon einen Gewinn, wenn es mehr als einmal im Programm aufgerufen wird. |
AW: Firebird 3.0 Order mit Feldname bei Union
Hallo,
sind denn die Feldnamen in den Tabellen gleich? |
AW: Firebird 3.0 Order mit Feldname bei Union
Zitat:
Sobald eine der Tabellen in rdb$relation_fields auch nur eine andere Reihenfolge bekommt, wird dir deine Konstruktion Felder zusammenbauen, die nix mitienander zu tun haben, kann auch dann zB die Spalte 18 sein, nach der zufälig gerade sortieren willst. Die reihenfolge ändert man zwar nicht zufällig, aber wenn doch, hast du einen rattenschwanz an problemen. Wenn nur eines der beiden Tabellen neue Felder bekommt, wird die Anweisung eh fehlerhaft sein und nicht ausgeführt werden können. Löse am besten das Problem gleich da wo es weit größer werden wird als nur bei dem Komfort. im Order by lesbarere Namen zu haben. Interaktiv einfach mal mit select * aubzurufen, was da kommt, ist immer legitim, in einer dauerhaft genutzen SQL Anweisung sollte das immer vermieden werden. |
AW: Firebird 3.0 Order mit Feldname bei Union
Hallo Holger,
ich wende im normalen Betrieb sehr sehr selten SELECT *. In diesem Fall hat es einen Grund. Es geht um einen Vorgang der alle Daten aller Tabellen bei Neuanlage und Änderung als JSON exportiert. Damit der Exporter immer zuverlässig funktioniert, auch wenn Felder neu hinzugekommen oder entfernt wurden, arbeitet der Prozess mit SELECT * Teilweise sogar generalisiert wobei der Tabellennamen über ein Makro übergeben wird. NUR in ein paar Tabellen habe ich eine Sonderbehandlung. Das UNION bindet ein paar Tabellen mit gleicher Struktur oder dieselbe Tabelle mit unterschiedlichem WHERE. Die Anzahl der Felder sind also immer garantiert identisch und wenn nicht, dann darf es zu einer Exception kommen, denn dann habe ich geschlafen. Gruß Kostas |
AW: Firebird 3.0 Order mit Feldname bei Union
Zitat:
Gruß Kostas |
AW: Firebird 3.0 Order mit Feldname bei Union
Ich nache da immer noch ein
Code:
drumrum. (Derived tables)
Select Feldliste from (
DeinUnionSelect ) order by ... Frank :oops:, der wurde ja bereits erwähnt... |
AW: Firebird 3.0 Order mit Feldname bei Union
Zitat:
perfekt genau so funktionierts.
Code:
Tausend Dank.
SELECT * FROM (
SELECT * FROM TABLE1 UNION SELECT * FROM TABLE2 ) ORDER BY FELDNAME |
AW: Firebird 3.0 Order mit Feldname bei Union
Zitat:
Grundsätzlich halte ich die Nutzung von Select * in Programmen (egal mit welcher Begründung) für fahrlässig.
SQL-Code:
funktioniert unter FireBird nicht.
SELECT Spalte1, Spalte2, und, weitere, Spalten
FROM TABLE1 UNION SELECT Spalte1, Spalte2, und, weitere, Spalten FROM TABLE2 ORDER BY Und Da müsste es korrekterweise dann eher
SQL-Code:
heißen.
SELECT Spalte1, Spalte2, und, weitere, Spalten from (
SELECT Spalte1, Spalte2, und, weitere, Spalten FROM TABLE1 UNION SELECT Spalte1, Spalte2, und, weitere, Spalten FROM TABLE2 ) ORDER BY Und Ändern sich (warum auch immer) mal die Spalten in einer der Tabellen und nehmen wir an, dass es sich immer um Spalten vom Typ Integer handelt, dann funktioniert bei einem * im Select auch sinngemäß sowas:
SQL-Code:
Das Gleiche mit Stern
SELECT Sum(Spalte1) as A, Sum(Spalte2) as b, Sum(und) as c, Max(weitere) as d, Spalten from (
SELECT Spalte1, Spalte2, und, weitere, Spalten FROM TABLE1 UNION SELECT und, Spalte1, weitere, Spalte2, Spalten FROM TABLE2 ) Group by a,b,c,d ORDER BY Spalten
SQL-Code:
wird auch funktionieren.
SELECT Sum(Spalte1) as A, Sum(Spalte2) as b, Sum(und) as c, Max(weitere) as d, Spalten from (
SELECT * FROM TABLE1 UNION SELECT * FROM TABLE2 ) Group by a,b,c,d ORDER BY Spalten Das kann dann durchaus auch mal in eine Art "Zufallsgenerator" ausarten, bei dem man zwar merkt, dass das Ergebnis irgendwie nicht hinhaut, aber bei der Ursachenforschung wird das dann verdammt haarig. Und wenn "on the fly" bei unterschiedlichen Datentypen an einer bestimmten Spaltenposition von der Datenbank eine Typkonvertierung erfolgen kann, dann funktioniert das Konstrukt via Select * immer noch.
SQL-Code:
wird datenbankseitig problemlos verarbeitet.
SELECT VarChar, VarChar, Integer, VarChar, Integer from (
SELECT VarChar, VarChar, Integer, VarChar, Integer FROM TABLE1 UNION SELECT Integer, Integer, Integer, Integer, Integer FROM TABLE2 UNION SELECT VarChar, VarChar, VarChar, VarChar, VarChar FROM TABLE3 ) ORDER BY Und Nur bei unterschiedlichen Spaltenzahlen wird es einen Fehler geben. Auf ein Zitat:
Oder anders formuliert: Ein Select * in einem Programm geht grundsätzlich nicht durch die Qualitätsprüfung. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:24 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz