dabadepdu
Datenbank-Guru
- Beiträge
- 1.789
Ich würde sonst halt einfach eine Funktion schreiben, und dann eine View mit dem aktuellen Jahr (diese Abfrage wird am häufigsten gebraucht) erstellen, aber bin auf deinen Vorschlag gespannt.Code:SELECT s.sid, s.bezeichnung, sum(p.a * p.b) AS flaeche FROM s,p WHERE s.sid = p.sid AND p.jahr1 <= 2004 AND ((p.jahr2) >= 2004 OR p.jahr2 IS NULL) GROUP BY s.sid,s.bezeichnung;
Was spricht dagegen, das Jahr in die Viewausgabe aufzunehmen? (und dann natürlich von außen zu parametrieren wie es grad gebraucht wird?)
(Klammer2: ich finde bei Datenbankabfragen ja auch immer toll, wenn man den Daten ansieht, wo sie herkommen. Also den Kontext mitliefern, nicht nur ein "Ergebnis". Hier konkret bei Ausgabe des Selects Jahr1 und Jahr2: "pass auf alter, das sind Daten für das Jahr 2004! - und nicht nicht was Du gerade meinst, weil Du beim Klick auf den Reportbutton kurz gepennt hast")
Oder: Wenn es ums Verrecken darum geht, so oft das aktuelle Jahr abzufragen, dem View die Bestimmung des aktuellen Jahrs zu überlassen?
Ja und wenn das alles nicht nach Deinem Geschmack ist, dann wäre es jenachdem ein schöner Anwendungsfall für Sessionvariables innerhalb eines Views.
+ Man hat einen schlanken View (statt einer Function),
+ man hat eine innere Einschränkung (ob jetzt mit offengelegten Parameterwerten oder nicht), die eine sofortig(st)e Mengeneinschränkung erlaubt
+ man hat eine übersichtlichere DB /Datenmodell (ohne Function)
- man ist nicht mehr ohne weiteres Stateless
Und nebenbei wegen Null oder nicht usw.:
Ich würde niemals auf Integerbasis mit Datumswerten arbeiten sondern immer mit Date, Datetime, Timestamp..
Ich würde außerdem auch aufwändige is (not) Null Abfragen vermeiden (entsprechend modellieren) (bei dates ist das ein ähnliches Problem wie bei Boolean Werte verglichen mit tri-state "bools")