"Umgedrehtes" LIKE-Statement?

[Mithrandir]

Hi ihr,

ich stehe gerade etwas aufm Schlauch. Wohl auch, weil mir für mein Problem kein Schlagwort einfällt. Folgendes Statement ist ja bekannt:

SQL-Code:

SELECT COUNT(*) FROM testseite WHERE spammail LIKE '[e-mail]';

Das würde alle Adressen in der Datenbank matchen, die ein "@mail.de" haben.

Nun hab ich es aber andersherum.
In der DB steht "*@mail.de", und ich komme mit "[e-mail]", "[e-mail]", "[e-mail]", usw usf. Wie kann ich jetzt eine passende SQL-Abfrage dazu bauen? Oder muss ich in diesem Fall mit PHP Vorarbeit leisten und den Teil vor "@mail.de" entfernen? Die obige Abfrage mit der richtigen Mailadresse führt leider nicht zum Erfolg.

[Matze]

Du meinst nicht zufällig das hier?

SQL-Code:

SELECT COUNT(*) FROM testseite WHERE spammail NOT LIKE '[e-mail]';

[jfheins]

Sowas vielleicht:

SQL-Code:

SELECT COUNT(*) FROM testseite WHERE '[e-mail]' LIKE spammail;

:?:

(Du musst aber natürlich das * durch % ersetzen)

[Mithrandir]

@Julius: Ja, genau das hab ich gesucht. Dass ich allerdings "*" durch "%" ersetzen muss, ist etwas.... unglücklich... :?

[Stevie]

Zitat:

Zitat von Daniel G

@Julius: Ja, genau das hab ich gesucht. Dass ich allerdings "*" durch "%" ersetzen muss, ist etwas.... unglücklich... :?

Es müsste doch ohne Problem folgendes gehen:

SQL-Code:

SELECT COUNT(*) FROM testseite WHERE '[e-mail]' LIKE replace(spammail, '*', '%');

[Mithrandir]

Hm, ich hab jetzt ein "Suchen&Ersetzen" über die SQL-Daten laufen lassen. :) Ich werd deinen Vorschlag beim nächsten Mal umsetzen. :)

[Valle]

Vorsicht!

LIKE ist generell sehr langsam, das sollte ja mittlerweile bekannt sein. Besonders ein LIKE mit Wildcards ist sehr langsam, da dieses nicht die eingestellten Indizes benutzen kann. Auch das Anwenden einer replace-Funktion auf eine Spalte macht die Datenbank unnötig langsam, da dieses replace auf ausnahmslos jeden Eintrag angewendet werden muss. Daher besser die Daten direkt mit "%" abspeichern. Wenn es sich um sehr viele Einträge handelt am besten noch einen anderen Weg suchen, sonst führt das besonders bei schwachen Servern schnell zum Exitus. :mrgreen:

Liebe Grüße,
Valle

[Mithrandir]

~32.000 Einträge in der Tabelle, vielleicht fünf mal am Tag aufgerufen. Meinst das passt? :) Weil mir ehrlich gesagt kein anderer Weg einfällt gerade. ;)

[alzaimar]

Zitat:

Zitat von Valle

Vorsicht!

Vorsicht! Bei Vorsicht! Erst testen, dann warnen!

Zitat:

Zitat von Valle

LIKE ist generell sehr langsam

Nö, nicht bei einer Suche à la "LIKE 'xyz%'" (also nur am Anfang). Ansonsten wird jeder Datensatz angefasst. Das stimmt. Aber ob ich da dann noch ein 'REPLACE' rüber jage, macht den Kohl auch nicht fett.

Allerdings kann man das auch schneller machen. Dazu müssten die Suchtexte und die Pattern in 'Wörter' bzw. Worteile zerlegt werden. Die kann man dann indizieren und schnell danach suchen. Aber bei 32k Einträgen und ein paar Zugriffen pro Tag... WTF. Da geht so schnell kein Server in den 'Exitus'..

[Valle]

Zitat:

Zitat von alzaimar

Nö, nicht bei einer Suche à la "LIKE 'xyz%'" (also nur am Anfang).

Das weiß ich, in dem Fall ist das aber nicht so...

Zitat:

Zitat von alzaimar

Ansonsten wird jeder Datensatz angefasst. Das stimmt. Aber ob ich da dann noch ein 'REPLACE' rüber jage, macht den Kohl auch nicht fett.

Das kommt auf die Menge an. Bei ~32000 ist das nicht wirklich relevant, da hast du Recht. Ich habe schon ganz andere Tabellen gesehen, da würde ich mir eher Gedanken machen. Ich konnte ja nicht wissen, um was für eine Tabelle es sich da handelt und wie oft das aufgerufen wird.

Ich bin auch der Meinung, es ist nie falsch, auf so Sachen aufmerksam zu machen. Die Tatsache, dass so ein Replace dann über alle Datensätze geht, ist durchaus wissenswert - egal ob an dieser Stelle nun relevant oder nicht.

Zitat:

Zitat von alzaimar

Allerdings kann man das auch schneller machen. Dazu müssten die Suchtexte und die Pattern in 'Wörter' bzw. Worteile zerlegt werden. Die kann man dann indizieren und schnell danach suchen. Aber bei 32k Einträgen und ein paar Zugriffen pro Tag... WTF. Da geht so schnell kein Server in den 'Exitus'..

Ich hoffe du hast mitbekommen, dass er die 32k erst erwähnte, als ich meinen Hinweiß schon geschrieben hatte! Aber Hauptsache mir erstmal unterstellen, ich hätte die Sache nie getestet oder erlebt. Mein nächster Post wäre gewesen, er sollte es doch mal testen bei den 32k. "Erst testen, dann warnen!" :(

Liebe Grüße,
Valle

[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