OT
Möglichkeit 3
Ich mag es ja selbst nicht, aber wie wärs mit der Verwendung von Views für den "Select Fall"?
Oder so: Was bietet die Select Procedure, was der View nicht kann?
Wenn SP für Select natürlich vom technisch versierten Unternehmensvorstand
als Direktive gesetzt ist, bleibt aber wohl keine Wahl.
Die viel beschworenen Geschwindigkeitsvorteile einer SP
Eine SP, die per Design den Client zwingt, (meistens) alle Datensätze zu laden, kann nur unter sehr speziellen Umständen einen Performancevorteil haben. (Einer wäre meinetwegen, sehr wenig Datensätze, 5 z.B.)
Zitat:
Möglichkeit 1
Eine SP, die dieses Design durch dynamischen Zusammenbau der Where Clause via String Parameter abschafft, kann nur schneller werden (außer z.B. bei den erwähnten 'sehr wenig Datensätzen')
Leider nicht ohne Nebenwirkungen, die Nachteile beim Einsatz von handgeklöppelten Strings statt Parametern sind ja bekannt.
Letztlich muss man wie immer abwägen, elegante Programm/Interfaces/Code, Bequemlichkeit für den Entwickler, Performance, Sicherheit ..
P.S.:
Zitat:
Möglichkeit 2
mit "künstlich" ergänzten Parametern scheint mir nicht unkritisch, sie verlangt einen soliden Optimizer, ein sehr gutes Auge bei der Klammersetzung bzw, hinreichende Testautomatisierung zur Prüfung der Kombis der Wherebedingungen. Das gilt natürlich je stärker, desto breiter die Tabelle ist (mehr Parameter) und je häufiger dieses Verfahren überhaupt eingesetzt wird.
/
OT
Edit: Da kann ich Thomas nur zustimmen.