Die dynamische Zusammensetzung von WHERE-Klauseln ist schon die richtige Lösung. Das geht ja auch mit anderen (Remote) Datenbanken genauso, obwohl die keine Makrosubstitution verstehen, aber man sendet ja ein SQL sowieso als String.
Es gibt dazu einerseits natürlich noch Stored Procedures, die eben compiliert sind und bei denen dann dynamisches SQL auch gerade deswegen verpöhnt ist, aber selbst innerhalb VFP bedeutet das jeweils einmalig compilieren für die Gesamt Abfrage und die Abfragedauer
übersteigt die Compilerzeit bei weitem. Es ist ja nicht so, daß pro Datensatz compiliert wird.
In meinen Anfangszeiten habe ich gerne mal selbst die SQL-Engine gespielt und selbst indizes gesetzt, relations gesetz, mit SEEK und SCAN REST oder SET KEY gearbeitet, und in vielen Situationen ist man damit sehr performant aber die relativ bessere Lesbarkeit
und übertragbarkeit auf andere Datenabnken macht SQL schon zur Wahl.
Die Diskussion wolltest Du jetzt zwar gar nicht anstoßen, aber das hängt insofern damit zusammen, daß man SQL schon als erste Wahl an und für sich nehmen kann. Und Makrosubstitution ist hier nicht unbedingt ein Frevel, der die Übertragbarkeit von Abfragen
reduziert.
Setzt man Abfragen Clientseitig dynamisch zusammen, und das kann man auch ohne Makrosubstitutionsoperator ja als String-Verkettung in jeder Client-Sprache und schickt eine solche Abfrage an einen SQL Server, dann nennt sich das AdHoc-Abfrage und ist völlig
erlaubt. Genauso fänt auch folgender Artikel an:
http://use-the-index-luke.com/de/sql/where/verstuemmelung/bedingte-klauseln
Das ist in dem Fall Ausschnitt aus einem Buch, was ich damit nicht empfehlen will, aber der Abschnitt ist schon ganz brauchbar.
Ich denke Du wirst eher viele gute Blogartikel in der Art finden, als solche Bücher. Wenn dann eher wie das hier auch eins ist, ein Buch über Performanceoptimierungen einer speeziellen Datenbank. Gute Abfragen zu schreiben ist ja nur eine Seite dieser Münze.
Tschüß, Olaf.
