nicht angemeldet
MySQL select mit like
Hallo Forum,
ich bin gerade dabei meine erste etwas größere PHP/MySQL Anwendung zu programmieren und bin dabei auf ein kleines Problem gestoßen, das ich zwar prinzipiell gelöst habe, aber mit dessen Lösung ich nicht wirklich froh bin, weil der select string dann endlos wird und ich mich gefragt habe, ob das nicht vielleicht auch etwas eleganter geht.
Es geht um folgende beispielhafte Abfrage:
"SELECT name,vorname FROM daten WHERE name LIKE '%$x%' OR vorname LIKE '%$x%'"
Das ist, wie gesagt, nur ein Beispiel, denn bei der Anwendung geht es darum, das in einer Adress-Datenbank der User die Möglichkeit haben soll, in allen Feldern entweder nach der id, einem Teil des Namens oder der Telefonnummer usw. nach diesem Eintrag zu suchen.
Die Tabelle hat jetzt allerdings ca. 10 Felder und das bedeutet ja, ich muß jedesmal "OR LIKE" ausformulieren. Gibt es nicht vielleicht eine Lösung die das ganze etwas verkürzt? Irgendwie sowas wie "switch" oder ähnliches? Zuerst hatte ich ja folgendes versucht:
"SELECT name,vorname FROM daten WHERE name,vorname LIKE '%$x%'"
Das erschien mir relativ logisch, funzt aber natürlich nicht. Weiß von euch also jemand eine Möglichkeit? Oder sind solche SQL-Abfragen eher unüblich?
Vielen Dank und Grüße
Ralf
-
Hm. Eigentlich gibt's wirklich keine "sehr elegante" Lösung.
Ich kann dir nur noch folgendes Anbieten:SELECT ... FORM ... WHERE CONCAT(name,vorname,...) LIKE '%$a%'
Gruss
Philipp
-
Hi!
Hm. Eigentlich gibt's wirklich keine "sehr elegante" Lösung.
SELECT ... FORM ... WHERE CONCAT(name,vorname,...) LIKE '%$a%'
Wieso sollte das denn nicht elegant sein?
Jedenfalls ist das gängige Praxis.Vielleicht noch eine kleine Anmerkung:
mal folgende Namen als Beispiel:
Karl Napp
Stefan Pudel
Anne Pfanne
Oliver SchluckDann macht das concat das draus:
"karlnappstefanpudelannepfanneoliverschluck"
Und das heisst, es würde auch "fanpudel", "nappste" oder "nepf" gefunden.
Wenn das nicht sein soll, muss halt noch ein Trennzeichen mitgegeben werden,
dass sonst nicht auftaucht.besser wäre also in dem Fall .. concat(vorname,"@",name,...)
Gruß,
Knud
-
SELECT ... FORM ... WHERE CONCAT(name,vorname,...) LIKE '%$a%'
Wieso sollte das denn nicht elegant sein?
Jedenfalls ist das gängige Praxis.Ja, stimmt eigentlich auch, aber .. WHERE name,vorname,... LIKE '..' wäre schon noch etwas "eleganter". Die Lösung mit CONCAT ist eine indirekte Lösung und somit nicht "vollkommen logisch". Die Lösung ist nicht elegant, aber das Mittel um trotzdem zum Ziel zu gelangen schon. Deshalb halte ich die Lösung für "schön", aber nicht "elegant". Eine "elegante" Lösung ist es, wenn eine Funktion direkt in mysql eingebunden wäre.
besser wäre also in dem Fall .. concat(vorname,"@",name,...)
In der Tat, so ist es noch viel besser, das kommt der "eleganten" Lösung schon sehr nahe.
Gruss
Philipp
-
Hi,
habe eben kräftig über das Wort "elegant" in euren Postings gelacht und wollte deshalb noch mal kurz was dazu schreiben.Das ganze hat nämlich folgenden Hintergrudnd:
Als ich angefangen habe zu programmieren, habe ich mir über sauberen und schönen Code überhaupt keinen Kopf gemacht, sondern das Zeug irgendwie reingehackt und die Hauptsache war immer, das es irgendwie lief. Bis ich mal ein paar Worte mit einem netten Kollegen ausgetauscht habe, der im Gegensatz zu mir Informatik studiert hat und der mir interessante Dinge aus diesem Studium berichtet hat. Kern des ganzen war nämlich, das in seinem Studium an der FH zwar schon programmiert wurde, aber ein ganz wichtiger Schwerpunkt immer auf "Software-Design" lag und das war ein Wort, das ich bisher in dieser Form gar nicht so kannte.Was ich aber kannte, das war das Problem, das ich nach zwei, drei Monaten meinen eigenen Code nicht mehr nachzuvollziehen konnte, weil konsequent auf Formatierung, Kommentare usw. verzichtet wurde, bzw. einfach angefangen wurde zu programmieren, ohne sich vorher mal ein paar Gedanken über Strukturierung, Datenflüsse usw. zu machen (Quick and dirty eben).
Und deshalb ging es natürlich nicht so sehr um "Eleganz" im eigentlichen Sinne, sondern eher darum, einen Code zu bauen, der im Rahmen meiner Möglichkeiten so übersichtlich wie möglich ist und deshalb habe ich mich gefragt, ob man das SQL - Statement nicht etwas kürzer und übersichtlicher gestalten kann, wobei ich schon das Gefühl habe, das es oft auch einfach in der Natur der Sache liegt, das SQL - Statements ziemlich, ziemlich fett werden können.
Gruß und Dank nochmals
Ralf-
Was ich aber kannte, das war das Problem, das ich nach zwei, drei Monaten meinen eigenen Code nicht mehr nachzuvollziehen konnte, weil konsequent auf Formatierung, Kommentare usw. verzichtet wurde, bzw. einfach angefangen wurde zu programmieren, ohne sich vorher mal ein paar Gedanken über Strukturierung, Datenflüsse usw. zu machen (Quick and dirty eben).
Leider mache ich das heute noch zu oft. Gott sei Dank habe ich ein ziemlich gutes Gedächtnis, was Sourcecodes betrifft.
Und deshalb ging es natürlich nicht so sehr um "Eleganz" im eigentlichen Sinne, sondern eher darum, einen Code zu bauen, der im Rahmen meiner Möglichkeiten so übersichtlich wie möglich ist und deshalb habe ich mich gefragt, ob man das SQL - Statement nicht etwas kürzer und übersichtlicher gestalten kann, wobei ich schon das Gefühl habe, das es oft auch einfach in der Natur der Sache liegt, das SQL - Statements ziemlich, ziemlich fett werden können.
so ab 1 A4-Seite mit diversen Joins, group by's und orders wirds wirklich unübersichtlich :-)
Ich glaube, dass unser Vorschlag eine akzeptable Länge aufweist, nicht? - Eine kürzere Version kann ich dir zumindest nicht mehr geben. Ich bin nun auch der Meinung, dass der Vorschlag mit CONCAT "elegant" ist. Ich habe "elegant" wohl mit "perfekt" vertauscht.
to be continued...
Philipp
-
Hi,
Ich glaube, dass unser Vorschlag eine akzeptable Länge aufweist, nicht? - Eine kürzere Version kann ich dir zumindest nicht mehr geben. Ich bin nun auch der Meinung, dass der Vorschlag mit CONCAT "elegant" ist. Ich habe "elegant" wohl mit "perfekt" vertauscht.
Jo. Ist auf jeden Fall eine coole Lösung, zumal wir hier gestern Abend noch einen längeren Diskurs gestartet haben, ob es überhaupt eine Alternative zum OR gibt. Ich habe das ganze mal vergleichsweise mit CONCAT und OR aufgeschrieben und es ist auf jeden Fall ein sehr, sehr deutlicher Unterschied, was die Länge und Übersichtlichkeit angeht.
Gruß Ralf
-> jetzt straight auf dem Weg zum 2 A4 Seiten Statement ;o)-
Hallo Ralf
Ich glaube, dass unser Vorschlag eine akzeptable Länge aufweist, nicht? - Eine kürzere Version kann ich dir zumindest nicht mehr geben. Ich bin nun auch der Meinung, dass der Vorschlag mit CONCAT "elegant" ist. Ich habe "elegant" wohl mit "perfekt" vertauscht.
Jo. Ist auf jeden Fall eine coole Lösung, zumal wir hier gestern Abend noch einen längeren Diskurs gestartet haben, ob es überhaupt eine Alternative zum OR gibt. Ich habe das ganze mal vergleichsweise mit CONCAT und OR aufgeschrieben und es ist auf jeden Fall ein sehr, sehr deutlicher Unterschied, was die Länge und Übersichtlichkeit angeht.Ich gebe zu, ihr habt mir auch ein wenig Kreativität abgefordert :-)
[ soll keine arrogante Anmerkung sein, nur Fakt, dass ich mich auch schwer getan habe um darauf zu kommen! ]-> jetzt straight auf dem Weg zum 2 A4 Seiten Statement ;o)
Viel Glück für die 2 A4 Seite :-)
und viele Grüsse
Philipp
-
-
-
-
-
-
Hi,
ausser der von Philipp angesprochenen Lösung, gibts IMHO nur noch die Möglichkeit der Einführung eines FullText-Index.
Weitere Infos darüber: http://www.mysql.com/doc/F/u/Fulltext_Search.html
Liebe Grüsse aus Österreich
Martin -
Hi,
vielen Dank für eure Mühe. Mit beidem kann ich was anfangen und gucke mir das mal in Ruhe anGrüße
Ralf