Tabellenübergreifender Index

[haentschman]

Zitat von DeddyH:

Nicht ganz richtig. Das gilt nur dann, wenn der Suchbegriff mit einer Wildcard beginnt, dann kann der Index nicht mehr genutzt werden.

da hätten wir

Code:

titel like '% %'

Wildcard vorn und hinten

PS: DeddyH hat Recht... wie immer

[DeddyH]

Das ist ja auch schnell erklärt. Nehmen wir mal an, wir sollen im Telefonbuch manuell nach Namen suchen (nehmen wir mal "Müller"). Heißt die Aufgabenstellung "suche mir alle Namen, die mit Müller beginnen", geht man ja so vor:
- Gehe zu "M", dann weiter zu "Mü", dann zu "Mül" usw.
- nun haben wir alle gesuchten schön untereinander stehen und können sie rausschreiben

Ändert man aber die Aufgabe in "suche mir alle, die Müller enthalten", bleibt einem nichts anderes übrig, als bei "A" zu beginnen und alle Einträge der Reihe nach zu untersuchen.

[idefix2]

Nein.

Die Abfragen 1 und zwei lauten genau gleich, abgesehen von der Sortierung.
Die bedingung like... ist in beiden Abfragen enthalten, nur wenn ich in der Sortierung zusätzlich zu Titel das Feld IP_NAME angebe, wird die Query so langsam. Und IP_NAME hat mit dem like nichts zu tun.

Habe jetzt zum Überprüfen die like Klausel in beiden Abfragen weggelassen, es ändert nichts am Zeitverhalten (über diese Klausel wurden nur die Datensätze selektiert, die mehr als ein Wort im Titel haben, und das sind fast alle - Der Query Optimizer behandelt das offenbar richtig).

Zitat:

ein Sprung ans Ende des Ergebnis-Sets
bedeutet was ?

Nach Eingabe des SQL Befehls werden die ersten ca 15 Datensätze angezeigt (die auf den Schirm passen), danach springe ich ans Ende zu letzten 15 Datensätze (von insgeasamt ca 55000)

[Sir Rufo]

Zitat von idefix2:

Nein.

Die Abfragen 1 und zwei lauten genau gleich, abgesehen von der Sortierung.
Die bedingung like... ist in beiden Abfragen enthalten, nur wenn ich in der Sortierung zusätzlich zu Titel das Feld IP_NAME angebe, wird die Query so langsam. Und IP_NAME hat mit dem like nichts zu tun.

Ja, aber wie hast du dir denn gedacht, soll der SQL-Server diese Sortierung durchführen?

IP_NAME ist ein berechnetes Feld ... also muss der SQL-Server zum Sortieren die ganze Tabelle aufbauen, dann Sortieren und kann Dir erst dann die Ergebnisse liefern.

Mich wundert es daher nicht, dass es erheblich länger dauert, wenn die Sortierung von IP_NAME hinzukommt.

[idefix2]

Es WUNDERT mich nicht allzusehr.

Wenn tabellenübergreifende Indizes oder berechnete Werte in Indizes möglich wären, würde es da kein Problem geben. Die Aufgabenstellung ist ja nicht wirklich sehr exotisch. Je mehr man sich bei der Datenbankdefinition der Normalform nähert, desto mehr Tabellen und damit Joins oder eben berechnete Spalten aus anderen Tabellen bekommt man. Wenn sich das so extrem auf die Performance niederschlägt, muss etwas faul sein.

Wobei ich eher annehme, dass es dafür eine Lösung gibt, und dass ich nur nicht weiss, wie sie aussieht. Deshalb dieser Thread.

[DeddyH]

Tja, mir fällt im Moment auch nichts mehr ein, Du könntest höchstens noch hier schauen: http://www.firebirdfaq.org/cat6/

[mkinzler]

Vielleicht wäre es eine Option das Feld nur für die Ergebnismenge und nicht für die gesamte Tabelle berechnen zu lassen