Abfrageergebnis in Query mehrmals nutzen

[InfoJunkie]

Hi alle,

auch wenn sich die Lösung meines Problems dem Thema nach einfach anhört, ist sie es IMO nicht.

Und zwar möchte ich in einer Abfrage (Abfr1) eine weitere Abfrage (Abfr2) absetzen und mit dem Ergebnis der Abfr2 weitere Berechnungen in Abfr1 durchführen.

Beispiel:

SELECT prozentwert AS prozent, prozentwert*(SELECT zahl FROM daten) FROM berechnung

Ich bräuchte sowas wie eine namentliche Referenzierung zum ersten ausgelesenen Wert, um damit in einer zweiten Abfrage rechnen zu können. Es sollte möglichst "DBMS-global" gehalten werden, also keine speziellen T-SQL oder PL/SQL-Befehle.

Hoffe ihr kennt euch besser aus als ich

nfo[J]unkie

[Goos]

Original geschrieben von InfoJunkie

Und zwar möchte ich in einer Abfrage (Abfr1) eine weitere Abfrage (Abfr2) absetzen und mit dem Ergebnis der Abfr2 weitere Berechnungen in Abfr1 durchführen.

Beispiel:

SELECT prozentwert AS prozent, prozentwert*(SELECT zahl FROM daten) FROM berechnung

nfo[J]unkie

Ich kann dein Problem nicht ganz erkennen. Als Abrf2 machst du dein SELECT zahl FROM daten und rechnest mit dem Ergebnis in Abfr1. Ist doch alles wunderbar und genau so wie du das willst?!?

Einzige Bedingung ist natuerlich, dass der Select auf zahl auch nur einen Wert zurueckliefert.

Goos

[InfoJunkie]

Hmm... ist irgendwie auch schwer zu erklären. Also ein neuer Versuch :

Ich hätte gern den folgenden TSQL-Block - habe ich nur mal so auf die Schnelle runtergetippt - auf Standard-SQL-Syntax (Oracle, MySQL) umgemünzt:

[ ... ]

BEGIN

     SET @mwst = (SELECT satz FROM tbl_mwst WHERE country = 'de')

     SELECT (netto*@mwst)/100 AS MWSt-Betrag FROM rechnung

     SELECT netto + (netto*@mwst/100) AS Rechnung-Betrag FROM rechnung

END

[ ... ]

Es ist so, dass der Select zu @mwst ca. 150 Zeilen fasst und mehrmals in der Query zu Berechnungen gebraucht wird. Bis jetzt ist es so, dass dann diese 150-Zeilen-Query jedes mal aufs Neue ausgeführt wird. Das soll sich nun ändern.

Das Problem hier sind die Variablen, da sie in jeder Sprache anders deklariert und gesetzt werden .

Die Änderung soll im Grunde nur die Querystruktur übersichtlicher gestalten (und das ganze performanter laufen lassen ). Gibt es da irgendwelche Möglichkeiten?

nfo[J]unkie

[just_me]

Du kannst mich jetzt ja für begriffsstutzig halten, aber: Hääääääää?

Es sollte möglichst "DBMS-global" gehalten werden, also keine speziellen T-SQL oder PL/SQL-Befehle.

Wechselt deine Datenbank sporadisch die Managementumgebung? Ich meine, du fährst doch auch nicht an der tankstelle vor, und lässt dir Rohöl in den Tank laufen, nur um sicherzugehen, dass du sowohl zum Benziner als auch zum Diesel kompatibel bist, oder?

Wenn dein statement serverseitig kalkuliert wird, gibt es keinen erkennbaren Grund, die Berechnungen nicht auch an die Umgebung anzupassen.

Wenn dein statement clientseitig kalkuliert werden soll (wovon gemäß deiner Spezifikation aber nicht auszugehen ist), gibt es keinen erkennbaren Grund, die Berechnungen nicht auch an die Umgebung anzupassen.

Das Problem dramatisiert sich sogar noch, wenn man berücksichtigt, dass du die differierende Variablen-Deklaration beanstandest.

Das Problem hier sind die Variablen, da sie in jeder Sprache anders deklariert und gesetzt werden

Gemäß SQL92-Standard ist es für RDBMS nicht einmal erforderlich, überhaupt Variablen deklarieren können zu müssen.

Das würde heißen, dass deine Anforderung

Die Änderung soll im Grunde nur die Querystruktur übersichtlicher gestalten

hinfällig wird, denn aus

     SET @mwst = (SELECT satz FROM tbl_mwst WHERE country = 'de')

     SELECT (netto*@mwst)/100 AS MWSt-Betrag FROM rechnung

     SELECT netto + (netto*@mwst/100) AS Rechnung-Betrag FROM rechnung

würde etwa das werden

SELECT 	(netto*(SELECT satz FROM tbl_mwst WHERE country='de'))/100, 

	(netto+((netto*(SELECT satz FROM tbl_mwst WHERE country='de'))/100)) FROM rechnung

Ok, zugegeben, es ist Geschmackssache, letzteres statement für "übersichtlicher" zu halten (insbesondere in Anbetracht der Tatsache, dass auch wahlfreie Attributbezeichner wegfallen müssen), aber deine nächste Anforderung wird (nicht zuletzt deswegen) definitiv NICHT erfüllt:

... und das ganze performanter laufen lassen ...

Allein infolge seiner Funktion ist ODBC nicht geeignet, performanter zu sein als proprietäre Treiber. Daher ist auch aus dieser Perspektive keine Möglichkeit (und kein Grund) erkennbar, dies zu realisieren.

Womit wir schließlich bei deiner Frage angekommen sind

Gibt es da irgendwelche Möglichkeiten?

Hier muss die Antwort eindeutig und zwangsläufig nein lauten.