Schlank, das war vielleicht das falsche Wort. Ein View ist für mich transparenter als eine Funktion, weniger mögliche Seiteneffekte, weniger Komplexität. Das würde ich immer bevorzugen. Ist vielleicht Geschmackssache, hat aber vielleicht auch was mit dem Thema Optimizer zu tun. Ganz generell gehe ich davon aus, dass ein View wahrscheinlich besser durch den Optimizer behandelt werden kann, als eine Funktion oder ein Selectstatement/ View mit enthaltener Funktion.
Das Prinzip von Sessionvariablen sehe ich da noch als deutlich kleineres Übel, weil sie keine strukturelle Komplexität in ein Statement bringen, sondern fast eher das Gegenteil. Funktional „reihen“ sie sich ein in herkömmlich verwendete Parameter, lediglich die Applizierung unterscheidet sich. Diese „völlige Unabhängigkeit“ kann ich zwar verstehen, betrachte es aber als total harmlos.
Ich habe unter Oracle sowas viel benutzt, wo es allerdings auch eleganter umsetzbar ist. Eleganterer Einsatz ändert aber nichts an der Wirkmacht (möglicher Performance Gewinn) einer Session Variable (bzw. Package Variable bei Oracle). Viel bedeutet dabei allerdings ein sehr bewusster Umgang (by Design), Session Variables werden über die ganze „Anwendung“ hinweg als Dimensionsobjekte benutzt, vielleicht eine Handvoll, z.B. eine Art Mandanten Paramter, ein Geschäftsjahr (siehe Thema des Threads und sowas). Das gilt dann systemweit und wird von Views, Prozeduren und Funktionen verwendet. Man kann so eine ganze, konsistente Datenschicht anlegen, ohne das ein Entwickler jemals aktiv diese Variable gesetzt hat (oder es vergessen kann). Aber es ist zu einem guten Teil sowieso hier Theorie, weil Sessionvariablen unter PG (noch- meinst Du das?) nicht soweit sind und weil ihr Einsatz systematisch eher für Client/Server Systeme als für Multi Tier in Frage kommt oder besser, für statefull Verbindungen.
Was die Grenzen des PG Optimizers angeht, bin ich nicht so gut im Bilde, weil ich dort noch keinen Bedarf hatte. Wenn Du sagst, dass da an der Stelle Schluss ist, meinetwegen. Aber diese Grenzen gibt es immer wieder und immer wieder woanders (in den verschiedenen RDBMS). Da würde ich 2 Bereiche unterscheiden. Kleine WaldUndWiesenAnwendung mit ein paar hundert T Datensätzen oder auch Millionen, jedenfalls unproblematisch und immer geeignet, straigt forward zu entwickeln. Da interessiert mich dann eben nicht, ob da grad mal doppelt oder alles aggregiert wird. (Ja, perspektivisch sollte es skalieren.) Da muss und sollte aber niemand primär an performance bedingte Strukturänderungen und denken (Stichwort premature Optimization). Und dann gibt es Großsysteme, wo Performance mitgedacht werden muss im Modell oder mindestens aber an vielen Stellen in Selectstatements.
Einen Tod muss man dann meist sterben, pragmatische, schnelle 0815 Entwicklung mit Performanceschwächen oder beste Performance mit ausgefeilter Modell- und Statement Optimierung und natürlich der sehr gezielten Nutzung spezifischer DB Fähigkeiten wie Partitionierung usw..
Die „is Null“ Sache sehe ich da eigentlich ähnlich wie Du. Mit NULL Werten wird man nie glücklich und man sollte sie nur einsetzen, wenn nicht anders möglich. Es ist sicher nicht die reine Lehre, dort dann magic numbers einzusetzen, vielleicht unkonventionell (wie Sessionvariables), aber in einem durchdesignten, geschlossenen System finde ich es okay.
Und wenn ich weder Sessionvariables noch doppelte Gruppierung, noch magic numbers haben möchte, kann man das Statement oben wahrscheinlich in einigen unterschiedlichen Varianten formulieren. Das machte aber für mich nur Sinn, wenn man Modell, Mengengerüste, Indizierung, Nutzungsfrequenz usw. wirklich kennt.
