nicht angemeldet
Hi!
Nach deiner Logik, müßte ich - wenn ich alle meine Abfragen in den Anwendungen darauf überprüfen wollte - dir alle hunderte Joins zeigen, damit du mir sagen kannst, in welchem Kontext ich mich bewege und ob im Einzelfall ein join oder ein subselect besser ist.
Nach meiner Logik müsstest du wissen, wie sich beide Verfahren bei welcher Datenlage verhalten. Es kann ja durchaus sein, dass je nach Anzahl der Datensätze und der Kardinalität[*] des Auswahlkriteriums sich die Laufzeiten unterschiedlich verhalten. In so einem Fall kannst du nur die zu erwartenden Daten einzuschätzen versuchen und dann die Schlussfolgerungen ziehen. Und es kann sein, dass im Laufe der Zeit die Datenlage anders wird und die einstmals optimale Abfrage keine solche mehr ist. Da hast du dann eine nach statistischen Erhebungen "meistens" schnelle Abfrage, die trotzdem wie eine Schnecke kriecht. Irgendwann helfen dir keine einfachen Regeln mehr und du brauchst das Hintergrundwissen sowie Kenntnisse beim Umgang mit den Profiler-Werkzeugen, um dir die genaue Sachlage anzuschauen.
[*] Je häufiger ein Wert vorkommt, desto weniger nützt ein Index, weil dieser dann die betroffene Datenmenge nicht genug einschränken kann. Wenn beispielsweise nur die Werte 0 und 1 vorkommen (angenommen zu je 50%), lohnt auf der Spalte kein Index, weil sowieso die Hälfte aller Datensätze in der Ergebnismenge sein muss und vielleicht ein full table scan diese Menge schneller liefert als das zusätzliche Lesen eines Index. (Nagel mich jetzt nicht auf dieser speziellen Aussage fest, ich bin kein Datenbankexperte. Aber es gibt solche Fälle, wo Indexe wegen vom Query-Optimierer vermuteter Ineffizienz ignoriert werden.)
Lo!
Struppi