hi Dominik
also, ich arbeite hauptsächlich mit oracle, aber die grundkonzepte werden ähnlich sein…
die laufzeit ist im wesentlichen von der datenmenge abhängig, die von der platte in den hauptspeicher geladen werden muss. natürlich geht auch zeit für was anderes drauf aber im wesentlichen sind es die platten-ios, die eine anwendung in die knie zwingen.
sowohl zugriffe auf die tabelle selbst als auch auf den index benötigt io. das ist wichtig, weil manche leute glauben, dass ein index eine suche automatisch schneller macht. im extremfall kann aber ein index die ios verdoppelt und damit das eigentliche problem darstellen.
zusätzlich muss man zwischen physischen ios auf die platte (laaaaangsam) und ios auf hauptspeicher (schnell) unterscheiden.
ein index auf eine spalte, auf die mit „like ‚%text%‘“ zugegriffen wird, ist reichlich unnötig, da hierfür der index nicht genutzt werden kann. spalten mit null-werten werden normalerweise nicht in den index aufgenommen, suchen mit „where column is null“ nutzen also auch nicht den index.
ganz wichtig und gerne ignoriert/vergessen: bereits beim definieren der datenstrukturen sollte man schon ein auge auf die zukünftigen suchabfragen werfen. designs laut lehrbuch, die brav in der 4. normalform sind, sind für den praxiseinsatz ev. unbrauchbar weil zu langsam (was nicht heisst, dass designs niedriger normalität automatisch besser sind!).
es gilt also, datenstruktur, indizes und suchabfragen gemeinsam aufeinander abzustimmen. hier ist auch die meiste performance aus einer anwendung herauszuholen.
dann gilt natürlich meist die milchmädchenrechnung „je mehr ram desto schneller“ (nicht immer aber meistens).
solange joins „sauber“ sind und nicht zu exzessiv gemacht werden, müssten sie für die performance wenig auswirkung haben: relationale datenbanken sind ja genau für diesen zweck konstruiert worden. im oracle ist es allerdings so, dass der optimizer ab einer gewissen anzahl an beteiligten tabellen nur mehr grobe schätzungen abgibt, da er die kombinationen nicht mehr in vernünftiger zeit berechnen kann (optimieren des statements würde länger dauern als ein full-table-scan).
im oracle kann man ein statement vom optimizer analysieren lassen, ohne es ausführen zu müssen. man bekommt dabei u.a. eine grobe schätzung, wieviele daten verarbeitet werden müssen. damit kann man wenigstens halbwegs fundiert eine schätzung über die laufzeit abgeben. ob ms sql irgendwas ähnliches anbietet, weiss ich allerdings nicht.
ich fürche allerdings, dass du auf verlorenem posten stehst, wenn der benutzer beliebige suchabfragen absetzen darf. gerade die kombination verschiedener kriterien bewirkt manchmal einen massiven einbruch in der performance - das alles auszuwerten, ist nicht gerade einfach.
am ehesten kann man sich normalerweise mit einem heuristischen ansatz helfen: einfach mal ein paar suchen durchprobieren und die zeiten messen, die kriterien vom benutzer mit den tests vergleichen und bei ähnlichen suchen ähnliche ausführungszeiten annehmen. je nachdem, wie der benutzer die suchabfragen zusammenstellen kann, ist das entweder sehr einfach oder ein riesen aufwand.
lg
erwin
