Index bei Like

[Furtbichler]

Zitat von himitsu:

...eine sortierte Liste der Hashs...

Bestimmt (imho) keine sortierte Liste von Hashes, denn das müsste auch ein B-Baum sein und wäre auch nicht schneller. Wenn, dann eine Art Hashmap. Da geht das Matchen in O(1), wogegen bei einem B-Baum vom Aufwand O(log n) ist, allerdings mit einer sehr großen Logarithmusbasis: Bei einer Seitengröße von 8k und 4-Byte Key immerhin log zur Basis 2000.

Gut, aber egal: Hash und Sortierung -> geht nicht -> LIKE geht auch nicht.

[dataspider]

Hi,

Firebird sollte hier einen Index verwenden, wenn dieser für das Feld STRASSE definiert ist.

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

where Strasse like :strasse

und dann den Parameter strasse auf 'Hauptst%' setzt.

Hier kann beim Prepare der Plan nicht ermittelt werden, da nicht klar ist, ob z.B. anstatt

'Hauptsr%' '%Hauptst%' als Wert für den Parameter kommt.


Frank

[EDIT]
Was ich auch schon hatte:
Die Selektivität des Index war irgendwie nicht funktionstüchtig...
Kann man mit
SET STATISTICS INDEX INDEX_NAME
neu berechnen lassen.
[/EDIT]

[Furtbichler]

Zitat von dataspider:

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

Code:

where Strasse like :strasse

Das ist aber eine ausgesprochene Schwäche von FB und ein 'fail by design'. Die könnten das Teil auch mit Index kompilieren: Zur Not scant der den Index eben, anstatt den Suchstring anhand der Sortierposition zu finden. Na ja.

[mkinzler]

Das Problem tritt aber auch bei anderen DBMS auf, sogar beim Microsoft SQLServer 2008 R2, dann ist dieser auch schlecht designed.

http://stackoverflow.com/questions/1...erformance-hit

[Furtbichler]

Zitat von Smut:

Furchti nörgelt halt gerne über Firebird... ich denke, er ärgert sich, dass er selbst nicht mit FB arbeitete

Sag mal, bist Du irgendwie weich in der Birne?

[dataspider]

Zitat von Furtbichler:

Zitat von dataspider:

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

Code:

where Strasse like :strasse

Das ist aber eine ausgesprochene Schwäche von FB und ein 'fail by design'. Die könnten das Teil auch mit Index kompilieren: Zur Not scant der den Index eben, anstatt den Suchstring anhand der Sortierposition zu finden. Na ja.

Hab ich auch lange drüber nachgedacht. Aber das Prepare ist nun mal vor der Zuweisung der Parameter.
Es ist ja wohl so gedacht, dass bei Benutzung der Parameter nur 1 Mal das Prepare erfolgen soll und nicht bei jeder Neuzuweisung eines Parameterwertes.
Die gewünschte Zeitersparnis geht hier natürlich in die Hose.
Mir würde es anders auch gefallen, aber ob das bei anderen DB' s besser gelöst ist, weiß ich nicht.
Ich bin übrigens schon in diese Falle getappt und Thomas Steinmaurer hat das näher erklärt...


Frank

[Bernhard Geyer]

Zitat von dataspider:

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

where Strasse like :strasse

und dann den Parameter strasse auf 'Hauptst%' setzt.

Hier kann beim Prepare der Plan nicht ermittelt werden, da nicht klar ist, ob z.B. anstatt

'Hauptsr%' '%Hauptst%' als Wert für den Parameter kommt.

Dann ist hier FB aber sehr mangelhaft implementiert.
In Zeichen von SQL-Injection und Co. sollte alle Abfragen Parametrisiert erfolgen.

Zitat von mkinzler:

Das Problem tritt aber auch bei anderen DBMS auf, sogar beim Microsoft SQLServer 2008 R2, dann ist dieser auch schlecht designed.
http://stackoverflow.com/questions/1...erformance-hit

Kenn dieses Problem beim MS SQL-Server wenn man varchar und nvarchar mischt. Dann wird oft auf Full-Table-Scan umgeschaltet.
Wenn man konsequent nur nvarchar verwendet ist mir das bisher nicht aufgefallen.

[mkinzler]

Zitat:

Dann ist hier FB aber sehr mangelhaft implementiert.
In Zeichen von SQL-Injection und Co. sollte alle Abfragen Parametrisiert erfolgen.

Ist halt nicht von Microsoft!