Tach!
Klar. Aber SQL hat ja eine Unmenge an Programmierlogig bereits integriert.
Ja, aber dazu müsstest du dich mit Stored Procedures befassen.
Ich meinte eigentlich noch simpler. Auch jede ("if-when-usw".) Abfrage ist ja schon Programmierlogig. (wenn auch in diesem Fall vielleicht nicht anwendbar).
Im SELECT ist nur Abfragelogik anwendbar. Damit kann man keine Programme schreiben, die nicht vorhandene aber berechenbare Daten als Ergebnisdatensätze hinzufügen.
Unkompliziert kann sein, aber performant ist das nicht bei steigender Anzahl der Daten. Es ist eine Abwägungsfrage, und es wird den Bereich geben, ab dem eine solche Vorgehensweise anfängt, auffallend Zeit zu verbrauchen. Bei wenigen Datensätzen wirst du nichts merken, vielleicht auch noch nicht bei wenigen hundert oder tausend oder wie auch immer. Aber bedenke, dass du pro Datensatz und pro Tag des Abfragezeitraums eine Query absenden must. Das läppert sich recht schnell zusammen.
Warum soll das bei zunehmenden Daten signifikant unperformanter sein? Solange der Abfragezeitraum z.b. auf 4 Wochen begrent ist, werden immer 28 Abfragen abgefeuert (natürlich auszuwählen aus einer steigenden Anzahl der Datenmenge).
28 Abfragen für jede Zeile der Datenbank, eventuell vorgefiltern mit der bereits fast fertigen Query. 28 mal X Kommunikation mit dem DBMS. Das ist nicht wenig.
Und in der Ergebnismenge finden sich jeweils die Daten für alle User dieses Tages. Oder was meinst du genau?
Ach, so herum meinst du das. Ja, das geht natürlich auch, das braucht dann "nur" 28 Abfragen und nicht 28 mal X. Das beschränkt die Anzahl doch mehr, also ich dacht. 28 ist aber trotzdem schon ganz ordentlich. Besonders wenn Netzwerk dazwischen liegt und das DBMS nicht auf derselben Maschine läuft.
dedlfix.