Nur Wörter ausgeben die mit "a" anfangen

[Eike]

Hi.
Ich möchte nur die Wörter habe die auch mit "a" oder "A" anfangen.
Ich stell mir das etwa so vor:

$result = mysql_query("SELECT * FROM tabelle WHERE erste Buchstabe='" . a . "'");

Nur weiß ich nicht wie ich "erste Buchstabe" in mysql übersetze.
Oder gibts da noch ne komplett andere möglichkeit?

[dedlfix]

echo $begrueszung;

Ich möchte nur die Wörter habe die auch mit "a" oder "A" anfangen.
$result = mysql_query("SELECT * FROM tabelle WHERE erste Buchstabe='" . a . "'");

Was hat denn das PHP mit deinem MySQL-Problem zu tun?

Schau im MySQL-Handbuch im Kapitel zu Funktionen und Operatoren nach LIKE

echo "$verabschiedung $name";

[Eike]

Ich bin verwirrt.
Jetzt kann ich das nicht mal richtig hinschreiben.

1.WHERE name LIKE '".d%."' <- Da gibt er mir die Fehlermeldung "Parse error: parse error, unexpected '.' in..." aus

2.Ok Punkt weg.
WHERE name LIKE '"d%"' <- Parse error: parse error, unexpected T_STRING in ...

3.Bei WHERE name LIKE d% <- Es geht schon besser aber es ist trotzdem falsch.

Das ist mein text:
$result1 = mysql_query("SELECT * FROM MBbilder WHERE name LIKE d% ");
while($row1 = mysql_fetch_array($result1))

Die zweite zeile des textes ist dann beim dritten das problem.
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in...

Was mach ich Falsch?

[Eike]

Hat sich schon erledigt!
muss ich natürlich einfach mit'' machen

[dedlfix]

echo $begrueszung;

Ich bin verwirrt.

Was mach ich Falsch?

Erstmal das PHP weglassen und die MySQL-Syntax in einer dafür besser geeigneten Umgebung probieren. Es bieten sich da beispielsweise phpMyAdmin an oder die von MySQL bereitgestellten Clients.

Damit vermischst du nicht mehr Fehler beim Schreiben des PHP-Codes mit denen, die du beim Schreiben des MySQL-Befehl machst :)

Strings müssen für MySQL in einfache oder doppelte Anführungszeichen gesetzt werden

SELECT * FROM MBbilder WHERE name LIKE 'd%'

Und wenn du diese Syntax richtig hinbekommen hast, dann kannst du sie in PHP-Code einbauen. Dabei ist zu beachten, dass das Vorkommen von einfachen Anführungszeichen in mit einfachen Anführungszeichen umschlossenen Strings entsprechend zu kennzeichnen ist. Gleiches gilt für doppelte Anführungszeichen in mit doppelten Anführungszeichen umschlossenen Strings.

Ist deine Verwirrung jetzt perfekt? :-)

echo "$verabschiedung $name";

[Rouven]

Hallo

Schau im MySQL-Handbuch im Kapitel zu Funktionen und Operatoren nach LIKE

ich weiß nicht wie das mit der Performance unter MySQL aussieht, aber evtl. sollte man mal ausprobieren wie sich das ganze entwickelt, wenn man statt LIKE einen Substring benutzt. Ist aber nur ein Experiment...

MfG
Rouven

[Axel Richter]

Hallo,

Schau im MySQL-Handbuch im Kapitel zu Funktionen und Operatoren nach LIKE
ich weiß nicht wie das mit der Performance unter MySQL aussieht, aber evtl. sollte man mal ausprobieren wie sich das ganze entwickelt, wenn man statt LIKE einen Substring benutzt. Ist aber nur ein Experiment...

Hm, da ich solche Vorschläge hier schon häufiger gelesen habe, frage ich mal. Wie kann man auf die Idee kommen, dass

... WHERE SUBSTRING(feld, 1, 1) = 'a' ...

einen Performancevorteil gegenüber

... WHERE feld LIKE 'a%' ...

haben könnte?

Warum ich das frage?

1. Der LIKE-Operator ist standardgemäß in allen SQL-Dialekten enthalten und also ist seine Umsetzung in der WHERE-Klausel mit Sicherheit in RDBMS performant implementiert, wogegen bei String-Funktionen meist erst ein String-Aggregat angeworfen werden muss.
2. Mit LIKE 'a%' kann ein eventell auf feld liegender Index _garantiert_ genutzt werden. Bei der String-Funktion kommt es auf deren Implementierung an, da sie _nicht_ zum Standard-SQL gehört, sondern in jedem RDBMS separat implementiert ist.
3. Die Lesbarkeit der Codes ist ja wohl bei LIKE viele besser. Außerdem kann man weit weniger komplex variable Inhalte mit Hilfe von serverseitigen Programmiersprachen einfügen.

viele Grüße

Axel

[Ilja]

yo,

Hm, da ich solche Vorschläge hier schon häufiger gelesen habe, frage ich mal. Wie kann man auf die Idee kommen, dass

... WHERE SUBSTRING(feld, 1, 1) = 'a' ...

einen Performancevorteil gegenüber

... WHERE feld LIKE 'a%' ...

haben könnte?

unter mysql wird das benutzen einer funktion mit sicherheit sogar ein nachteil sein, da dann im gegensatz zu LIKE ohne führendes % kein index benutzt wird.

Ilja

[e7]

Hi,

1. Der LIKE-Operator ist standardgemäß in allen SQL-Dialekten enthalten und also ist seine Umsetzung in der WHERE-Klausel mit Sicherheit in RDBMS performant implementiert, wogegen bei String-Funktionen meist erst ein String-Aggregat angeworfen werden muss.

muss nicht sein... Es könnte ja auch sein, dass der Programmierer eines DB-Systems den Like-Operator selber basteln muss und da langsamen Mist zusammenbastelt, aber bei den Stringfunktionen auf fertigen, effizienten Code zugreifen kann...

E7

[Ilja]

yo,

muss nicht sein... Es könnte ja auch sein, dass der Programmierer eines DB-Systems den Like-Operator selber basteln muss und da langsamen Mist zusammenbastelt, aber bei den Stringfunktionen auf fertigen, effizienten Code zugreifen kann...

selbst wenn das so wäre, was meiner meinung nach sehr unwahrscheinlich ist, würde das nicht mehr dafür sprechen, das dbms zu wechseln anstelle auf den LIKE operator zu verzichten ?

Ilja

[Rouven]

Hallo,

na ja, meiner Einschätzung nach hängt da viel von den Optimierungen seitens DBMS ab. So wäre einer der Gedanken hinter der Substring-Sache, dass durch das Beschneiden die Suche auf eine feste Länge eingeschränkt ist, in diesem Fall sogar ein Character, also ein Maschinenwort, das auf Bitebene direkt abgeglichen werden könnte.
Davon abgesehen, wir haben bei einer DB2 5 oder 6 mal damit rumgespielt, in Datenbeständen jenseits der 10Mio Datensätze auf Feldern von 32 Charactern, da war das Bild etwas zweigeteilt. Zum einen ist es zwar korrekt, dass die Stringfunktionen alles andere als gut sind, zum anderen war es aber tatsächlich so, dass wir an einigen Stellen Suchfunktionen auf Substring umgestellt haben weil sie schlichtweg schneller waren als mit einem LIKE% - warum auch immer...

MfG
Rouven

[Axel Richter]

Hallo,

Davon abgesehen, wir haben bei einer DB2 5 oder 6 mal damit rumgespielt, in Datenbeständen jenseits der 10Mio Datensätze auf Feldern von 32 Charactern, da war das Bild etwas zweigeteilt. Zum einen ist es zwar korrekt, dass die Stringfunktionen alles andere als gut sind, zum anderen war es aber tatsächlich so, dass wir an einigen Stellen Suchfunktionen auf Substring umgestellt haben weil sie schlichtweg schneller waren als mit einem LIKE% - warum auch immer...

Bist Du sicher, dass es sich dabei um das angesprochene Problem, also WHERE feld LIKE 'a%' vs. WHERE SUBSTRING(feld, 1, 1) = 'a' gehandelt hat?

Bei WHERE feld LIKE '%a%' vs. WHERE SUBSTRING(feld, 3, 1) = 'a' oder WHERE feld LIKE '%a' vs. WHERE RIGHT(feld, 1, 1) = 'a' sieht die Sache nämlich _natürlich_ ganz anders aus ;-). Da kann die String-Funktion ihren Vorteil ausspielen, wei LIKE erstens _auch_ einen Full-Table-Scan ohne Indexnutzung ausführen muss und zweitens die Stringfunktion _hier_ wirklich _nur_ die relevanten Feldinhaltsteile zu betrachten hat, während das 'a' in LIKE '%a%' ja im gesamten Feldinhalt stehen kann.

viele Grüße

Axel