mehrere Abfragen, aber NUR WENN Sie auch da sind ;_)

[Rolf B]

Hallo pl,

das ist letztlich ein generischer Filter, mit dem eine Table mit X Spalten nach (fast) jeder Spalte filtern kann. Für einen Excel-verwöhnten Bürohengst nichts Besonderes (für die Bürostuten auch nicht).

Die berechtigte Frage ist aber - ist das sinnvoll. Solange die Tabelle klein ist, sind solche Abfragen schnell. Wenn aber Volumen in der DB steckt, werden die meisten Abfragen dieser Art zu Table Scans führen, weil es garantiert nicht zu jeder Spalte einen Index geben wird. Hier führt die Excel-Denke in die Katastrophe, weil nämlich ein Web-Request nicht davon ausgehen kann, der einzige zu sein der auf der DB herumturnt.

Das heißt, taisön: Man KANN sowas bauen, indem man einfach eine Bedingung nach der anderen an's WHERE anklebt, aber SOLLTE man? Da müssen vorher Fragen geklärt sein:

• wieviele User sind unterwegs
• wie groß ist die abgefragte Table (wieviele Rows)?
• wie häufig werden solche Universalabfragen gemacht

Und wenn jetzt das Unbehagen anfängt zu grummeln, wäre die nächste Frage:

• Welche Abfragen werden wirklich gebraucht?
• Oder zumindest: Welche Abfragen sind häufig

Und für die muss man dann die Queries und ggf. die DB optimieren. Dies ist das Web. Kein Single-User PC. Es gibt ein Sprichwort: Das schlimmste, was einer Webanwendung passieren kann, ist Erfolg. Denn Erfolg bedeutet viele User. Und diejenigen, die mit Single-User Techniken gebaut wurden, knicken dann ein. Sobald die erste Query zu langsam ist, stauen sich die Abfragen. Und danach wird es nur noch schlimmer. Erfahrene Operatoren stellen eine Schüssel Mais auf den Server. Sobald das Popcorn fliegt, gibt es ein größeres Problem.

Rolf