"Umgedrehtes" LIKE-Statement?

[alzaimar]

Zitat:

Zitat von Valle

Das weiß ich...

Zitat:

Zitat von Valle

LIKE ist generell sehr langsam...Besonders ein LIKE mit Wildcards ist sehr langsam

Das geht aus deinem Beitrag so nicht hervor. Denn wieso ist ein LIKE "(generell) sehr langsam", wenn es doch -soweit es geht- vorhanden Indexe benutzt? Hinterher behaupten:"Das weiss ich doch" kann Jeder. :lol: (Los! schmunzel du nun auch mal!)

Zitat:

Zitat von Valle

Zitat:

Zitat von alzaimar

...Aber ob ich da dann noch ein 'REPLACE' rüber jage, macht den Kohl auch nicht fett.

Das kommt auf die Menge an.

Nein. Ein Replace arbeitet mit (so gut wie) konstantem Overhead pro Record und ist im Vergleich zur restlichen Performance eher vernachlässigbar. (Overhead ca. 2-3%, gemessen über 1Mio Recs).

Zitat:

Zitat von Valle

Ich konnte ja nicht wissen, ... und wie oft das aufgerufen wird.

Doch? :gruebel: Ein mal pro Record? :mrgreen:

Zitat:

Ich bin auch der Meinung, es ist nie falsch, auf so Sachen aufmerksam zu machen.

Das stimmt. Ich habe es auch nicht negiert, sondern nur präzisiert und einige deiner Behauptungen in Frage gestellt bzw. imho korrigiert.

Zitat:

Ich hoffe du hast mitbekommen, dass er die 32k erst erwähnte, ... Aber Hauptsache ... unterstellen

Nun nimm doch nicht alles so persönlich. Ich unterstelle doch Nichts, aber wenn es so rüberkam: Entschuldigung.

Du hast pauschale Aussagen gemacht, die so einfach nicht korrekt waren. Das es "besonders bei schwachen Server zum Exitus kommt", weil eine Query mit LIKE abgesetzt wird(was 'generell sehr langsam' ist :zwinker: ) kann man auch nicht unkommentiert stehen lassen, denn das ist auch zu pauschal. Denn auch ein 8xCPU-Server mit 20GHZ und 1TB RAM geht bei idiotischen Queries in die Knie.

Meine Anmerkung: "Erst probieren, dann warnen" zielte auf deine pauschalen und nicht verifizierten Aussagen. Hättest Du erst den REPLACE-Overhead gemessen, und dein Wissen über die Verwendung von Indexen bei LIKE-Operatoren verwendet, müsste dein Beitrag eigentlich anders aussehen.

Zitat:

Mein nächster Post wäre gewesen, er sollte es doch mal testen bei den 32k.

Klar, hinterher weiss man es immer besser. :lol:

Aber eins kann man stehen lassen:

Zitat:

Zitat von Valle

Daher besser die Daten direkt mit "%" abspeichern.

Da fällt mir noch etwas ein: Du möchtest einen String über sehr viele Suchpattern jagen? Da gibt es Algorithmen, die sich auf soetwas spezialisiert haben. Stichwort: Multiple Pattern Matching Hat nix mit SQL zu tun, muss es auch nicht, denn ein SQL-Server ist keine Patternsuchmaschine.

[Valle]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Valle

Ich konnte ja nicht wissen, ... und wie oft das aufgerufen wird.

Doch? :gruebel: Ein mal pro Record? :mrgreen:

Ich meinte wie oft das Query aufgerufen wird. ;-)

Ich habe mich bezüglich des LIKE-Statements etwas unpräzise ausgedrückt. Das Wort 'generell' war an dieser Stelle schlichtweg fehl am Platz. LIKE kann bei richtiger Anwendung natürlich auch schnell sein. So wie Daniel seine Datenbank hat, braucht man sich auch keine Sorgen zu machen. Wenn ich aber so an manch selbst gebaute Foren-Software denke, die ihre Suchfunktion mit LIKE macht und man mit 2-3 Leuten einen DDoS auf dem Server erzugen konnte... :stupid:

Ansonsten kein Grund dich zu entschuldigen, ich habe nichts persönlich genommen.

... dass ein LIKE mit Wildcard am Ende die Indizes dennoch benutzt wusste ich aber wirklich. :mrgreen:

Liebe Grüße,
Valle