Dynamisches SQL mehrere where klauseln

[BenderD]

Und warum denn nicht?
Solange die Original-Spalte auf der linken Seite des Vergleichsoperators (BETWEEN) nicht verändert wird (z.B. durch eine Scalare Funktion) KANN der Optimizer einen regulären Binary Radix Tree Index verwenden.
Ob er es denn tut, hängt mit anderen Faktoren zusammen.

... und selbst wenn auf der linken Seite des Vergleichsoperators die Spalte verändert wird, kann der Optimizer sogar einen entsprechenden Derived Index verwenden.

Kleiner Tipp: bevor man irgendwelche Behauptungen in den Raum stellt, sollte man das Ganze doch mal ausprobieren.

... das Schnittmuster (Bild oben) interessiert mich wenig. Entscheidend ist, wie die Selektivität der einzelnen Bestandteile der where Klausel ist, wenn sich der Optimizer da verschätzt, dann geht das eh' in die Grütze. Mein Vorschlag ist gut lesbar (man sieht sofort, was gemeint ist) und praktisch erprobt, man sollte natürlich die Indexe mit den zu erwartenden where Klauseln aufeinander abstimmen, sprich: die mit der hohen Selektivität (z. B. Firma o.ä.9 nach vorne nehmen und diei Exoten (Telefonnummer o.ä) nach hinten.

D*B