Hallo! > Angenommen ich m�chte 100 000 Datens�tze einer Tabelle, die Benutzer enth�lt > durchsuchen.... > die Bedingung ist, dass die ID des users zwischen 10 000 und 20 000 liegt > und der Name mit "J" anf�ngt - das Beispiel ist ausgedacht. > > Dann sieht das ja etwa so aus: > "where id gr��ergleich 10 000 & id kleinergleich 20 000 und left(name, 1) = > "J"... > > So, sind also drei Bedingungen.. > wie macht das die DB jetzt ?
Also zun�chst einmal die Relevanz der Frage: In meiner SQL Server Datenbank befinden sich in einer Tabelle 159.000 Datens�tze mit W�rtern, die bis zu 50 Buchstaben haben k�nnen. Wenn ich jetzt das Wort Relevanz r�ckw�rts geschrieben suche (where reverse(word) = 'znaveler'), dann braucht der SQL Server daf�r 331 Millisekunden. In dieser Zeit liest er die Spalte komplett ein, f�hrt die Funktion f�r jede einzelne Zeile aus und schickt mir das Ergebnis zur�ck. Wenn ich die ganze Datei sortiert nach reverse(word) ausgebe, dann braucht er 21 Sekunden, allerdings weniger als 1 Sekunde f�r das Einlesen und sortieren und der Rest f�r die Anzeige der Daten. Ich meine, dass die Datenbank an sich so schnell ist, dass die Frage nicht so relevant ist, weil die meiste Zeit eh f�r das �bertragen der Daten zur Applikation aufgewendet wird. Da Access ca. 20 bis 25 mal langsamer ist als SQl Server, hat die Frage hier schon mehr Bedeutung. Aber immer liegt das Optimierungspotential �berwiegend in der zu �bertragenden Datenmenge. Bei der Suche nach LIKE 'j%' bekommst Du wahrscheinlich 500, bei LIKE 'b%' allerdings wohl 7.000 Treffer. Insofern d�rfte die Suche nach LIKE 'j%' deutlich scheller abgehen als die Suche nach LIKE 'b%'. Jetzt zu Deiner WHERE-Klausel: Korrekt w�re "where ([id] between 10000 and 20000) and ([name] like 'j%')". Schon damit bist Du schneller als mit der Funktion "LEFT". Wenn Du einen Index auf "name" hast, wird der bei "LIKE 'j%'" benutzt (allerdings nicht bei '%j%'). Die zus�tzliche Angabe des Index �ber die ID ist dann eher hinderlich (es sei denn, es w�rde die Ergebnismenge zus�tzlich einschr�nken). Verwende also ausschlie�lich "WHERE [name] LIKE 'J%'" mit Index auf [name] und versuche bei den h�ufig verwendeten Buchstaben wie "B" oder "N" oder "S" mindestens einen zweiten Buchstaben zu bekommen. Ziel muss es sein, so wenig Daten wie m�glich zu �bertragen. Es macht ja auch keinen Sinn, seinen Namen aus einer Selectbox mit 7.000 Eintr�gen zu w�hlen, zumal dabei auch nicht jeder Browser mitspielen d�rfte. Es gibt auch den Effekt, dass ein Index nicht nur das INSERT, DELETE oder UPDATE sondern auch das SELECT behindert: N�mlich genau dann, wenn die Suchmenge schon recht klein ist. Wenn man (nur noch) in weniger als 30 Datens�tzen sucht, bringt der Index sogar einen Nachteil, weil die Spalte ja zweimal gelesen wird. SQL Server arbeitet die WHERE-Klausel optimiert ab, selektiert also zun�chst die indizierten Spalten. Wie das bei Access ist, wei� ich nicht. Wenn Du ganz sicher gehen willst, kannst Du das Select schachteln: select * from (select * from ... where [id] between 10000 and 20000) where [name] like 'j%' Beim SQL Server d�rfte das allerdings keinen Unterschied machen. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
