Hallo,
ich habe in meinem Select mehrere Case Abfragen drinn.
Ist es möglich den Wert in 'Case' in der Then oder Else noch mal zu verwenden?
CASE (SELECT lange Abfrage) is null then 'text' else (SELECT lange Abfrage) end AS Spaltenname
So würde doch die Select-Anweisung 2 mal ausgeführt werden, d.h. einmal umsonst.
.
Du könntest das Ergebnis in eine Variable stecken.
Declare @CaseValue nvarchar(50) -- Als Beispiel
SET @CaseValue = Select foo from Table Where foo = foo;
CASE (@CaseValue)
Jörg
Hm ... 🤔
So wie ich das sehe wird das Select Statement nur einmal ausgeführt.
Das 2. liegt ja in einem Else Block.
Das mit der Variable klingt nach nen overkill 🙂
Wenn du dir aber Schreibarbeit sparen willst, würde ich über einen dynamischen Zusammenbau des SQL Strings nachdenken.
Kann natürlich auch ein overkill sein .... kommt immer drauf an wie exzessiv das ganze genutzt wird.
PS:
Generell kann man selbstverständlich Zwischenwerte in Variablen packen. Es kommt aber immer auf den Kontext an, ob es Sinn macht oder nicht.
Gruß,
Tom
Hallo zusammen,
sind hierfür nicht Views gedacht? Ich habe noch kein solches Konstrukt bei einer DB-Abfrage gesehen.
Ich würde die Abfrage in einer View abspeichern. Dann kann man überprüfen ob das Ergebniss Treffer hatte, oder nicht, und dementsprechend reagieren.
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Das mit der View habe ich schon probiert, allerdings läßt der mich keine Views mit Parameter speichern.
Geht das mit den Variablen nur bei Prozeduren oder auch normalen SQL Abfragen?
Variablen gehen in nativen Statements sowie Procedures.
Weiss jetzt gar nicht ob die in Views auch funktionieren.
Btw, das mit dynamisch zusammenbauen, meinte ich eher vom Server Code aus.
Gruß,
Tom
Danke.
Wer das mit den Variablen mal probieren.
Ja, die Queries werden im Code zusammen gebaut. Ich hatte vorher diese Problematik auch mit 2 oder mehreren Abfragen hintereinander gelößt.
Nur war die Performance einfach misst. Habe festgestellt wenn ich die Komplexität in den SQL Server ausagere, eine deutlich bessere Gesamtperformance erhalte.
Hallo zusammen,
Nur war die Performance einfach misst. Habe festgestellt wenn ich die Komplexität in den SQL Server ausagere, eine deutlich bessere Gesamtperformance erhalte.
Einer mehr, der anfängt Datenbanken zu verstehen 😉
Ich bin immer der Meinung: Nur die DB weiß, wie sie am schnellsten eine Befehlsfolge abarbeitet. Deshalb bin ich auch ein Freund, dass man so viel Logik wie möglich in die DB packen sollte.
Weiter so, auch wenn es anstrengend ist...
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Naja das mit der Speed auf der DB würd ich bei 99% der "normalen" Fälle zustimmen 🙂
Wenn man sich aber ein bisschen mit Ausführungsplänen und Kostenabschätzungen beschäftigt, merkt man recht fix was man tunlichst auf der DB vermeiden sollte.
Dazu gehören z.B. komplexe String Operationen ^^
Gruß,
Tom
Hallo TOM,
völlig richtig, man sollte natürlich nur so viel Datenbanklogik in die DB packen, und nicht anfangen darin zu "programmieren".
Stimmt, das kann man laut meiner Aussage auch falsch verstehen.
Ich denke das sollte jedem klar sein (hoffentlich), dass eine DB nicht auf "Rechnen" spezialisiert ist, sondern nur darauf, wie und in welcher Reihenfolge Daten per Anfrage an den Mann kommen.
Gruß
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”