like

Hallo Leute,

folgende Situation:
in meiner DB (mysql) habe ich eine Tabelle Ort. In der Tabelle Ort sind
verscheidene Orte (war ja klar). Jede zeile hat auch ein Spalte plz für die
Postleitzahl. In manchen plz-Feldern stehen nun mehrere plz, also z.B.
02453,02486,02684.
Um einen teffer bei eienr Abfrage zu erhalten benutzer ich like.

der releante Teil des Abfragestrings sieht nun so aus:

$mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";

Das ergibt dann im mysql:
ort.plz like "%1006_114.plz%"

Und damit sucht jetzt mysql nach dem string 1006_114.plz.

Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
wird.

Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
Abfrage.
Wie muß ich denn nun die Abfrage schreiben, damit wirklich nach dem Wert
aus 1006_114.plz und nicht nach dem String 1006_114.plz gefragt wird?

So sieht der gesamte String aus:

SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,
1006_114.strasse, 1006_114.plz, ort.ort, 1006_114.tel1, 1006_114.www,
1006_114.mail, 1006_114.logo, 1006_114.keywords, 1006_114.standard1,
1006_114.standard2, 1006_114.standard3, 1006_114.standard4, 1006_114.tag,
1006_114.monat, 1006_114.jahr, 1006_114.aktuell, 1006_114.vert_nummer,
1006_114.ranking, landkreis.landkreis, bundesland.bundesland,
branche.branche, 1006_114.tel2, 1006_114.fax1, 1006_114.fax2,
1006_114.funk1, 1006_114.funk2
FROM 1006_114, ort, landkreis, bundesland, branche
WHERE ort.ort_ID = 1006_114.ort
AND ort.plz LIKE "%1006_114.plz%" <<< und hier hängt es
AND ort.landkreis_ID = landkreis.landkreis_ID
AND ort.bund_ID = bundesland.bund_ID
AND branche.branchen_ID =114
AND bundesland.bundesland = "Sachsen"
AND landkreis.landkreis = "Leipzig"
ORDER BY 1006_114.standard4, 1006_114.standard3, 1006_114.standard2,
1006_114.standard1, 1006_114.ranking, 1006_114.firma

mfg

Mathias

Re: like

Mathias Fiedler schrieb:
> Hallo Leute,
>
> folgende Situation:
> in meiner DB (mysql) habe ich eine Tabelle Ort. In der Tabelle Ort sind
> verscheidene Orte (war ja klar). Jede zeile hat auch ein Spalte plz für die
> Postleitzahl. In manchen plz-Feldern stehen nun mehrere plz, also z.B.
> 02453,02486,02684.

Desinfehler.

> Um einen teffer bei eienr Abfrage zu erhalten benutzer ich like.
>
Sag' ich ja.

> der releante Teil des Abfragestrings sieht nun so aus:
>
> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
>

Hm. Das sieht nicht wie SQL aus. Nicht jeder spricht Perl!

> Das ergibt dann im mysql:
> ort.plz like "%1006_114.plz%"
>

> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>
> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
> wird.
>

Dann hast Du offenbar eine Perl-Frage (oder welche Programmiersprache
auch immer Du benutzt), denn Du weißt ja schon, wie die SQL-Abfrage
aussehen muss. Für Programmiersprachen gibt es andere Newsgruppen

> Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
> Abfrage.
> Wie muß ich denn nun die Abfrage schreiben, damit wirklich nach dem Wert
> aus 1006_114.plz und nicht nach dem String 1006_114.plz gefragt wird?
>

Das ist hier Off-topic.

Grundsätzclich solltest Du aber das Design Deiner Tabelle überdenken.
Was Du da gebastelt hast, schließt die Verwendung eines Index bei der
PLZ-Suche aus - abgesehen davon, dass man in relationalen Datenbanken
tunlichst *nicht* mehrere Werte in *einem* Feld speichern sollte.


> So sieht der gesamte String aus:
>
> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,

Deine TABELLE heißt 1006_114? Grusel.

Re: like

Am Fri, 03 Mar 2006 13:44:00 +0100 schrieb Christian Kirsch:

> Mathias Fiedler schrieb:
>> Hallo Leute,
>>
>> folgende Situation:
>> in meiner DB (mysql) habe ich eine Tabelle Ort. In der Tabelle Ort sind
>> verscheidene Orte (war ja klar). Jede zeile hat auch ein Spalte plz für die
>> Postleitzahl. In manchen plz-Feldern stehen nun mehrere plz, also z.B.
>> 02453,02486,02684.
>
> Desinfehler.
>
Ich sehe das anders, aber das löst nicht das Problem.

>> Um einen teffer bei eienr Abfrage zu erhalten benutzer ich like.
>>
> Sag' ich ja.
>
>> der releante Teil des Abfragestrings sieht nun so aus:
>>
>> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
>>
>
> Hm. Das sieht nicht wie SQL aus. Nicht jeder spricht Perl!
Es ist php. Das Problem liegt ja bei der Schreibweise in mysql. Auch die
Abfrage in der mysql Konsole eingegeben bringt das gleiche Problem.
>
>> Das ergibt dann im mysql:
>> ort.plz like "%1006_114.plz%"
>>
>
>> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>>
>> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
>> wird.
>>
>
> Dann hast Du offenbar eine Perl-Frage (oder welche Programmiersprache
> auch immer Du benutzt), denn Du weißt ja schon, wie die SQL-Abfrage
> aussehen muss. Für Programmiersprachen gibt es andere Newsgruppen
>
Wieder nicht richtig. Die Abfrage, wie oben beschrieben ist reines mysql,
ledglich generiert von php. Die Frage bleibt immer noch bestehen.
ort.plz like "%1006_114.plz%" fragt nach dem String 1006_114.plz. Wie muß
ich die Scheibweise ändern damit nicht nach dem String, sondern nach dem
Wert aus dem angegebenen Feld gesucht wird. Das ist mysql !


>> Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
>> Abfrage.
>> Wie muß ich denn nun die Abfrage schreiben, damit wirklich nach dem Wert
>> aus 1006_114.plz und nicht nach dem String 1006_114.plz gefragt wird?
>>
>
> Das ist hier Off-topic.
>
> Grundsätzclich solltest Du aber das Design Deiner Tabelle überdenken.
> Was Du da gebastelt hast, schließt die Verwendung eines Index bei der
> PLZ-Suche aus - abgesehen davon, dass man in relationalen Datenbanken
> tunlichst *nicht* mehrere Werte in *einem* Feld speichern sollte.
>
>
Das Design meiner Tabelle ist schon ok. Das Gleiche Problem könnte
auftreten, wenn man in einer Spalte typ Text etwas sucht. Dafür gibt es ja
unter anderem like. Und ich habe nicht gebastelt, sondern mir wohl Gedanken
darüber gemacht.

>> So sieht der gesamte String aus:
>>
>> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,
>
> Deine TABELLE heißt 1006_114? Grusel.

Das zu beurteilen war hier nicht gefragt. Das ist eine Beurteilung meiner
Arbeit, die Dir nicht zusteht! Das Gesamtprojekt erfordert eine solche
Darstellung. Aber auch das tut trotzdem nichts zur Sache und ist mehr
OffTopic als meine Frage.

Re: like

Mathias Fiedler wrote:
> Am Fri, 03 Mar 2006 13:44:00 +0100 schrieb Christian Kirsch:
>
>> Mathias Fiedler schrieb:
>>> Hallo Leute,
>>>
>>> folgende Situation:
>>> in meiner DB (mysql) habe ich eine Tabelle Ort. In der Tabelle Ort sind
>>> verscheidene Orte (war ja klar). Jede zeile hat auch ein Spalte plz für die
>>> Postleitzahl. In manchen plz-Feldern stehen nun mehrere plz, also z.B.
>>> 02453,02486,02684.
>> Desinfehler.
>>
> Ich sehe das anders, aber das löst nicht das Problem.

Du darfst das gerne anders sehen, solltest dich dann aber nicht darüber
wundern, dass du für deine Ansichten und Designentscheidungen
letzendlich das falsche Werkzeug benutzt. SQL ist für soetwas *nicht*
gemacht, sondern bietet unter dem Oberbegriff "Normalisierung" Regeln
an, die eine Organisation der Daten für die einfache Abfrage mittels SQL
ermöglicht.

>>> Um einen teffer bei eienr Abfrage zu erhalten benutzer ich like.
>>>
>> Sag' ich ja.
>>
>>> der releante Teil des Abfragestrings sieht nun so aus:
>>>
>>> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
>>>
>> Hm. Das sieht nicht wie SQL aus. Nicht jeder spricht Perl!
> Es ist php. Das Problem liegt ja bei der Schreibweise in mysql. Auch die
> Abfrage in der mysql Konsole eingegeben bringt das gleiche Problem.

Du bist hier in der MySQL Newsgroup. Wir erwarten von dir ein
entsprechedes Entgegenkommen und Aufbereiten der Abfragen. Es ist für
dich sicherlich kein Problem, den PHP-Schmodder vor dem Posten zu
entfernen und einfach zu lesendes SQL anzubieten.

>>> Das ergibt dann im mysql:
>>> ort.plz like "%1006_114.plz%"
>>>
>>> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>>>
>>> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
>>> wird.
>>>
>> Dann hast Du offenbar eine Perl-Frage (oder welche Programmiersprache
>> auch immer Du benutzt), denn Du weißt ja schon, wie die SQL-Abfrage
>> aussehen muss. Für Programmiersprachen gibt es andere Newsgruppen
>>
> Wieder nicht richtig.

Ähm, legst du es drauf an, Antworten zu bekommen?

> Die Abfrage, wie oben beschrieben ist reines mysql,
> ledglich generiert von php. Die Frage bleibt immer noch bestehen.
> ort.plz like "%1006_114.plz%" fragt nach dem String 1006_114.plz. Wie muß
> ich die Scheibweise ändern damit nicht nach dem String, sondern nach dem
> Wert aus dem angegebenen Feld gesucht wird. Das ist mysql !

Du plenkst.

Vielleicht suchst du LIKE 1006_114.plz? Oder LIKE
CONCAT('%',1006_114.plz,'%')?

>>> Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
>>> Abfrage.
>>> Wie muß ich denn nun die Abfrage schreiben, damit wirklich nach dem Wert
>>> aus 1006_114.plz und nicht nach dem String 1006_114.plz gefragt wird?
>>>
>> Das ist hier Off-topic.
>>
>> Grundsätzclich solltest Du aber das Design Deiner Tabelle überdenken.
>> Was Du da gebastelt hast, schließt die Verwendung eines Index bei der
>> PLZ-Suche aus - abgesehen davon, dass man in relationalen Datenbanken
>> tunlichst *nicht* mehrere Werte in *einem* Feld speichern sollte.
>>
>>
> Das Design meiner Tabelle ist schon ok.

Nein.

> Das Gleiche Problem könnte
> auftreten, wenn man in einer Spalte typ Text etwas sucht. Dafür gibt es ja
> unter anderem like. Und ich habe nicht gebastelt, sondern mir wohl Gedanken
> darüber gemacht.

Wenn man etwas in einer Spalte vom Typ TEXT speichert, dann sind das
Daten, die nur in ihrer Gesamtheit zusammengehörig sind. Wenn man darin
etwas sucht, dann nimmt man dafür eher weniger LIKE, sondern einen
Volltextindex.

Das was du hast ist ein Speichern von Daten, die zusammenhängend (in
einem Feld zusammenhängend) keinen Sinn haben, sondern erst dann, wenn
man sie an einem ominösen Listentrennzeichen ',' aufsplittet und einzeln
betrachtet. Das ist innerhalb von relationalen Datenbanken, für deren
Verwendung du dich entschieden hast, designtechnisch Quatsch - dafür
gibt es 1:n Beziehungen.

Wenn du das anders siehst - wie gesagt: gerne. Aber du darfst dich nicht
darüber wundern, wenn man dir vorwirft das falsche Werkzeug oder das
Werkzeug falsch zu benutzen.

>>> So sieht der gesamte String aus:
>>>
>>> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,
>> Deine TABELLE heißt 1006_114? Grusel.
>
> Das zu beurteilen war hier nicht gefragt. Das ist eine Beurteilung meiner
> Arbeit, die Dir nicht zusteht!

Wenn du das nicht vertragen kannst, dann frag nicht. Ich verweise an
dieser Stelle auf die Signatur von Markus Mann in
<2ie132Flvd49U1@uni-berlin.de>:

Du fragst nach Schminke, um die Pusteln auf Deiner Haut zu kaschieren
und jeder hier merkt "Oh mein Gott, er hat $SCHLIMME_KRANKHEIT" und rät
Dir "Geh' zum Arzt". Du haelst jetzt alle fuer nicht-hilfsbereit, weil
Dir keiner geeignete Schmike nennen will. [Matthias P. Wuerfl in dclpd]

> Das Gesamtprojekt erfordert eine solche Darstellung.

Es wurde verboten, Buchstaben, Wörter und sprechende Namen für
Tabellennamen zu verwenden? LOL! Aber wenn ich mir die Inhalte der
Tabellenfelder anschaue, dann wundert mich das nicht wirklich.

Grüße
Kai

Re: like

Mathias Fiedler schrieb:
> Am Fri, 03 Mar 2006 13:44:00 +0100 schrieb Christian Kirsch:

>>> der releante Teil des Abfragestrings sieht nun so aus:
>>>
>>> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
>>>

>>
> Wieder nicht richtig. Die Abfrage, wie oben beschrieben ist reines mysql,

mysql> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near '$mysql = $mysql."ort.plz like
\"%$tabelle_verwendet.plz%\" AND "' at line 1

Sieht so aus, als ob Du einen Bug-Report schreiben müsstest - MySQL
versteht kein reines mysql. Gut, dass Du das gemerkt hast.


> Das Design meiner Tabelle ist schon ok. Das Gleiche Problem könnte

Nein. Wenn Du in *einem* PLZ-Feld mehrere PLZ-Werte speicherst, dann
ist das Design kapott. Weshalb Du ja auch mit LIKE nach einer PLZ
suchen willst, statt mit =.

> auftreten, wenn man in einer Spalte typ Text etwas sucht. Dafür gibt es ja
> unter anderem like. Und ich habe nicht gebastelt, sondern mir wohl Gedanken
> darüber gemacht.
>

Das Ergebnis überzeugt nicht.

>>> So sieht der gesamte String aus:
>>>
>>> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,
>> Deine TABELLE heißt 1006_114? Grusel.
>
> Das zu beurteilen war hier nicht gefragt.

Ich fürchte, Du brauchst einen "diese Antwort hätte ich lieber
nicht"-Filter.

Nochmal zu Deinem ursprünglichen Posting:

> Das ergibt dann im mysql:
> ort.plz like "%1006_114.plz%"
>
> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>
> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
> wird.
>
> Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
> Abfrage.

Mit anderen Worten: Du *weißt*, was Du in MySQL schreiben musst. Du
weißt bloß nicht, wie Du das in PHP ausdrücken sollst. Vermutlich kann
Dir de.comp.lang.php.datenbanken o.ä. weiter helfen.

Re: like

Mathias Fiedler wrote:
>> Desinfehler.
>>
> Ich sehe das anders, aber das löst nicht das Problem.

Ds ist eine der Ursachen für das Problem, da mit einem
vernünftigen Design kein LIKE nötig wäre. Und auch
performancetechnisch ist dieser Ansatz eine mittlere
Katastrophe da keine Indizierung möglich ist.

>> Hm. Das sieht nicht wie SQL aus. Nicht jeder spricht Perl!
> Es ist php. Das Problem liegt ja bei der Schreibweise in mysql. Auch di=
e
> Abfrage in der mysql Konsole eingegeben bringt das gleiche Problem.

dann wärst du in de.comp.lang.php.datenbanken vermutlich
besser aufgehoben

>>> Das ergibt dann im mysql:
>>> ort.plz like "%1006_114.plz%"
>>>
>>> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>>>
>>> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 ges=
ucht
>>> wird.

Und noch einmal: Designfehler, mit einem vernünftig normalisierten
Design hättest du hier einen einfachen JOIN benutzen können

>> Grundsätzclich solltest Du aber das Design Deiner Tabelle überdenk=
en.
>> Was Du da gebastelt hast, schließt die Verwendung eines Index bei de=
r
>> PLZ-Suche aus - abgesehen davon, dass man in relationalen Datenbanken=

>> tunlichst *nicht* mehrere Werte in *einem* Feld speichern sollte.
>>
>>
> Das Design meiner Tabelle ist schon ok. Das Gleiche Problem könnte
> auftreten, wenn man in einer Spalte typ Text etwas sucht. Dafür gibt =
es ja
> unter anderem like. Und ich habe nicht gebastelt, sondern mir wohl Geda=
nken
> darüber gemacht.

und noch einmal: es ist *nicht* ok

Wenn Du Dein Design tatsächlich nicht normalisieren willst dann ist

LIKE CONCAT('%',1006_114.plz,'%')

vermutlich die richtige Lösung, aber performancetechnisch ist das
eine komplette Katastrophe.


>>> So sieht der gesamte String aus:
>>>
>>> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorna=
me,
>> Deine TABELLE heißt 1006_114? Grusel.
>=20
> Das zu beurteilen war hier nicht gefragt. Das ist eine Beurteilung mein=
er
> Arbeit, die Dir nicht zusteht! Das Gesamtprojekt erfordert eine solche
> Darstellung. Aber auch das tut trotzdem nichts zur Sache und ist mehr
> OffTopic als meine Frage.

Diese Namensgebung lässt allerdings vermuten das hier noch weitere
Design-Sünden vorliegen. Irgendwie habe ich den Eindruck das diese
Tabellennamen selbst Informationen tragen und viele gleichartige
Tabellen dieser Art existieren, zB eine je Kunde. Ich kann mich da
zwar vollkommen irren, aber der Verdacht drängt sich schon irgendwie
auf ...

--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/

Re: like

Am Fri, 03 Mar 2006 15:51:24 +0100 schrieb Kai Ruhnau:

> Mathias Fiedler wrote:
>> Am Fri, 03 Mar 2006 13:44:00 +0100 schrieb Christian Kirsch:
>>
>>> Mathias Fiedler schrieb:
>>>> Hallo Leute,
>>>>
>>>> folgende Situation:
>>>> in meiner DB (mysql) habe ich eine Tabelle Ort. In der Tabelle Ort sind
>>>> verscheidene Orte (war ja klar). Jede zeile hat auch ein Spalte plz für die
>>>> Postleitzahl. In manchen plz-Feldern stehen nun mehrere plz, also z.B.
>>>> 02453,02486,02684.
>>> Desinfehler.
>>>
>> Ich sehe das anders, aber das löst nicht das Problem.
>
> Du darfst das gerne anders sehen, solltest dich dann aber nicht darüber
> wundern, dass du für deine Ansichten und Designentscheidungen
> letzendlich das falsche Werkzeug benutzt. SQL ist für soetwas *nicht*
> gemacht, sondern bietet unter dem Oberbegriff "Normalisierung" Regeln
> an, die eine Organisation der Daten für die einfache Abfrage mittels SQL
> ermöglicht.
>
>>>> Um einen teffer bei eienr Abfrage zu erhalten benutzer ich like.
>>>>
>>> Sag' ich ja.
>>>
>>>> der releante Teil des Abfragestrings sieht nun so aus:
>>>>
>>>> $mysql = $mysql."ort.plz like \"%$tabelle_verwendet.plz%\" AND ";
>>>>
>>> Hm. Das sieht nicht wie SQL aus. Nicht jeder spricht Perl!
>> Es ist php. Das Problem liegt ja bei der Schreibweise in mysql. Auch die
>> Abfrage in der mysql Konsole eingegeben bringt das gleiche Problem.
>
> Du bist hier in der MySQL Newsgroup. Wir erwarten von dir ein
> entsprechedes Entgegenkommen und Aufbereiten der Abfragen. Es ist für
> dich sicherlich kein Problem, den PHP-Schmodder vor dem Posten zu
> entfernen und einfach zu lesendes SQL anzubieten.
>

Erst mal ist das kein PHP-Schmodder. Das ist eine Programmiersprache, wie
viele ander auch. Damit man den sql teil erkennt gab es noch diese Zeile:
Das ergibt dann im mysql:
ort.plz like "%1006_114.plz%"

Aus den beiden Schreibweisen heraus ergab sich meine Fragestellung.
Aus meiner Sichtr völlig ok.

>>>> Das ergibt dann im mysql:
>>>> ort.plz like "%1006_114.plz%"
>>>>
>>>> Und damit sucht jetzt mysql nach dem string 1006_114.plz.
>>>>
>>>> Ich möchte aber, das nach dem Feld plz aus der Tabelle 1006_114 gesucht
>>>> wird.
>>>>
>>> Dann hast Du offenbar eine Perl-Frage (oder welche Programmiersprache
>>> auch immer Du benutzt), denn Du weißt ja schon, wie die SQL-Abfrage
>>> aussehen muss. Für Programmiersprachen gibt es andere Newsgruppen
>>>
>> Wieder nicht richtig.
>
> Ähm, legst du es drauf an, Antworten zu bekommen?
Auf diese Aussage? Nein !
>
>> Die Abfrage, wie oben beschrieben ist reines mysql,
>> ledglich generiert von php. Die Frage bleibt immer noch bestehen.
>> ort.plz like "%1006_114.plz%" fragt nach dem String 1006_114.plz. Wie muß
>> ich die Scheibweise ändern damit nicht nach dem String, sondern nach dem
>> Wert aus dem angegebenen Feld gesucht wird. Das ist mysql !
>
> Du plenkst.
>
> Vielleicht suchst du LIKE 1006_114.plz? Oder LIKE
> CONCAT('%',1006_114.plz,'%')?
>
Ich habe nicht geplenkt. Das obige war genau die Lösung. Ich habe nicht
nach Lehrstunden über Datenbankdesign und das Für und Wider von
Tabellennamen gefragt, sondern eine Problemstellung aufgezeigt, für die
concat die Lösung war. Ganz einfach.

>>>> Wenn ich nämlich eingebe: ort.plz like "%04752%" , dann funktioniert meine
>>>> Abfrage.
>>>> Wie muß ich denn nun die Abfrage schreiben, damit wirklich nach dem Wert
>>>> aus 1006_114.plz und nicht nach dem String 1006_114.plz gefragt wird?
>>>>
>>> Das ist hier Off-topic.
Quatsch
>>>
>>> Grundsätzclich solltest Du aber das Design Deiner Tabelle überdenken.
>>> Was Du da gebastelt hast, schließt die Verwendung eines Index bei der
>>> PLZ-Suche aus - abgesehen davon, dass man in relationalen Datenbanken
>>> tunlichst *nicht* mehrere Werte in *einem* Feld speichern sollte.
>>>
>>>
>> Das Design meiner Tabelle ist schon ok.
>
> Nein.
>
>> Das Gleiche Problem könnte
>> auftreten, wenn man in einer Spalte typ Text etwas sucht. Dafür gibt es ja
>> unter anderem like. Und ich habe nicht gebastelt, sondern mir wohl Gedanken
>> darüber gemacht.
>
> Wenn man etwas in einer Spalte vom Typ TEXT speichert, dann sind das
> Daten, die nur in ihrer Gesamtheit zusammengehörig sind. Wenn man darin
> etwas sucht, dann nimmt man dafür eher weniger LIKE, sondern einen
> Volltextindex.
>
Warum will mir nur immer jeder seine Meinung von Dingen aufzwingen nach
denen ich gar nicht gefragt habe? Meine Fragestellung war doch eindeutig!
Wo bitte habe ich danach gefragt, ob mein Datenbankdesign richtig ist oder
nicht? Ich habe nun mal für mcih so entschieden. Für meine Problemstellung
gibt es eine Lösung. Das sehen wir ja ein paar Zeilen weiter oben. Warum
kann man es nciht einfach dabei belassen? gegen Hinweise und Informationen
habe ich überhaupt nichts einzuwenden, aber wenn man dabei die eigentliche
Problemstellung aus den Augen verliert, sind sie fehl am Platz!

> Das was du hast ist ein Speichern von Daten, die zusammenhängend (in
> einem Feld zusammenhängend) keinen Sinn haben, sondern erst dann, wenn
> man sie an einem ominösen Listentrennzeichen ',' aufsplittet und einzeln
> betrachtet. Das ist innerhalb von relationalen Datenbanken, für deren
> Verwendung du dich entschieden hast, designtechnisch Quatsch - dafür
> gibt es 1:n Beziehungen.
>
> Wenn du das anders siehst - wie gesagt: gerne. Aber du darfst dich nicht
> darüber wundern, wenn man dir vorwirft das falsche Werkzeug oder das
> Werkzeug falsch zu benutzen.
>
Doch, darüber wundere ich mich. Denn das löst nicht meine Frage. Es mag ja
durchaus möglich sein, das Du die Datenbank anders aufgebaut hättest.
Vielleicht werde auch nochmal eine Änderung vornehmen.Es kann durchaus
sein, dass ich das falsche Werkzeug habe.
Aber ich habe nun mal den Gesamtüberblick über mein Projekt. Und das ist in
php, von dem Du ja nichts wissen willst. Für mich war das Datenbankdesign
für dieses Projekt durchaus in Ordnung. Es hat sich während der Arbeit
daran herausgestellt, das einiges hätte anders bzw. besser gestaltet werden
können. Aber damit kann ich mich für die Version 3.0 befassen. Jetzt muß
die 2.0 fertig werden. Und da muß ich mit dem auskommen, was ich habe. Und
um dort ein Problem zu lösen, kann ich nicht komplett von vorn anfangen.
Auch wenn Du das anders siehst, ich habe eben eine andere Meinung.
>>>> So sieht der gesamte String aus:
>>>>
>>>> SELECT 1006_114.firma, 1006_114.anrede, 1006_114.name, 1006_114.vorname,
>>> Deine TABELLE heißt 1006_114? Grusel.
>>
>> Das zu beurteilen war hier nicht gefragt. Das ist eine Beurteilung meiner
>> Arbeit, die Dir nicht zusteht!
>
> Wenn du das nicht vertragen kannst, dann frag nicht. Ich verweise an
> dieser Stelle auf die Signatur von Markus Mann in
> <2ie132Flvd49U1@uni-berlin.de>:
>
Das hat nichts mit vertragen zu tun. Das ist eine subjektive Beurteilung
meiner Arbeit ohne den Zusammenhang zu kennen.


> Du fragst nach Schminke, um die Pusteln auf Deiner Haut zu kaschieren
> und jeder hier merkt "Oh mein Gott, er hat $SCHLIMME_KRANKHEIT" und rät
> Dir "Geh' zum Arzt". Du haelst jetzt alle fuer nicht-hilfsbereit, weil
> Dir keiner geeignete Schmike nennen will. [Matthias P. Wuerfl in dclpd]
>
Na das ist aber nun wirklich ausgemachter Blödsinn !
>> Das Gesamtprojekt erfordert eine solche Darstellung.
>
> Es wurde verboten, Buchstaben, Wörter und sprechende Namen für
> Tabellennamen zu verwenden? LOL! Aber wenn ich mir die Inhalte der
> Tabellenfelder anschaue, dann wundert mich das nicht wirklich.
>
Das sind von einem System generierte Tabellen. Woher Du die Inhalte kennst,
ist mir schleierhaft. Ich habe nur ein Feld aufgezeigt. Ob das irgendwen
wundert oder nicht, ist auch nicht von Belang. Damit wird die Frage nicht
beantwortet, sondern nur unnötiger Traffic verursacht.

Gruß

Mathias
> Grüße
> Kai

Re: like

>
> Wenn Du Dein Design tatsächlich nicht normalisieren willst dann ist
>
> LIKE CONCAT('%',1006_114.plz,'%')
>
> vermutlich die richtige Lösung, aber performancetechnisch ist das
> eine komplette Katastrophe.
>
>
Warum eigentlich ist concat so schlimm ?
Es löst mein Problem und ich merke keinen Nachteil in der Performance.

Gruß
Mathias

Re: like

Mathias Fiedler wrote:

***viel senf***

Ach sag doch gleich, daß du ins Killfile willst.


frank

Re: like

Mathias Fiedler wrote:

[unbedeutend]


**Rrring** **Rrring**

H: "Hallo, Sie sprechen mit der kostenlosen Hotline von Werkzeug-
Müller, Herr Hilfreich am Apparat. Wie kann ich Ihnen helfen?"

R: "Rudi Ratlos hier. Ich habe ein Problem mit dem Hammer aus dem
Werkzeugkasten aus Ihrem Haus."

H: "Und das wäre?"

R: "Also ich versuche hier dieses Scharnier an der Holztruhe zu
befestigen. Aber ich bekomme die Schrauben mit dem Hammer nicht
richtig rein. Die Schraubenköpfe stehen über und jetzt schließt
der Deckel nicht richtig."

H: "Aber warum nehmen sie denn den Hammer dafür? Für Schrauben haben
sie doch die Schraubendreher in Ihrem Werkzeugkasten..."

R: "Papperlapapp! Mit dem Schraubendreher habe ich es versucht, aber
da geht *gar* *nichts*. Ich glaube, Sie haben mir da Schund
angedreht. Mit dem Hammer geht es zwar, aber eben nicht richtig.
Auch Schund!!1elf!"

H: "Bitte mäßigen Sie sich. Natürlich müssen Sie die Löcher für die
Holzschrauben erst vorbohren. Den Bohrer finden Sie auch in ihrem
Werkzeugkasten, gleich links neben ..."

R: "SCHWEIGEN SIE! Ich will jetzt eine Lösung, wie das mit dem Hammer
geht! Das muß gehen!"

H: "Also so wie Sie das angehen, wird das nie was.
Ich möchte nicht wissen, wie der Rest von Ihrer Holztruhe aussieht."

R: "Das geht Sie GAR NICHTS an! Was maßen Sie sich,
meine Arbeit beurteilen zu wollen! Danach habe ich Sie gar nicht
gefragt!" ...

H:


PS: du stehst mit einem Bein im Killfile


XL

Re: like

Mathias Fiedler schrieb:
>>Wenn Du Dein Design tatsächlich nicht normalisieren willst dann ist
>>
>> LIKE CONCAT('%',1006_114.plz,'%')
>>
>>vermutlich die richtige Lösung, aber performancetechnisch ist das
>>eine komplette Katastrophe.
>>
>>
>=20
> Warum eigentlich ist concat so schlimm ?
> Es löst mein Problem und ich merke keinen Nachteil in der Performance=


Wenn du schon vorher LIKE "%irgendwas%" verwendest, kann die Performance =

auch nicht weiter in den Keller gehen...

--=20
Gruss,
Fabian

Re: like

Mathias Fiedler wrote:

>>> dem Wert aus dem angegebenen Feld gesucht wird. Das ist mysql !
>>
>> Du plenkst.
>>
>> Vielleicht suchst du LIKE 1006_114.plz? Oder LIKE
>> CONCAT('%',1006_114.plz,'%')?
>>
> Ich habe nicht geplenkt.

Also soweit ich das sehe, steht oben zwischen dem Wort mysql und dem '!'
eindeutig ein Leerzeichen. Wie kannst Du dann behaupten, daß Du nicht
plenkst?

> Das obige war genau die Lösung. Ich habe nicht
> nach Lehrstunden über Datenbankdesign und das Für und Wider von
> Tabellennamen gefragt, sondern eine Problemstellung aufgezeigt, für die
> concat die Lösung war. Ganz einfach.

Es zwingt Dich ja niemand, ein gut verarbeitbares Design zu wählen. Und wenn
Du, wie Du weiter unten schreibst, unter Zeitdruck bist, und so auf die
Schnelle das Design nicht ändern kannst, dann ist es ok, aber Du mußt Dich
halt mit Performance-Einbußen zufrieden geben.

>>> Das Design meiner Tabelle ist schon ok.

Auch wenn es funktioniert - eine LIKE '%...%'-Abfrage *ist* langsam, auch
wenn Du Dich jetzt auf den Kopf stellst.


> gegen Hinweise und Informationen
> habe ich überhaupt nichts einzuwenden, aber wenn man dabei die eigentliche
> Problemstellung aus den Augen verliert, sind sie fehl am Platz!

Wenn aber beides Hand in Hand geht, dann gehören solche Hinweise eben dazu.


> Doch, darüber wundere ich mich. Denn das löst nicht meine Frage. Es mag ja
> durchaus möglich sein, das Du die Datenbank anders aufgebaut hättest.
> Vielleicht werde auch nochmal eine Änderung vornehmen.Es kann durchaus
> sein, dass ich das falsche Werkzeug habe.

Immerhin.

[numerische Tabellennamen]

> Das hat nichts mit vertragen zu tun. Das ist eine subjektive Beurteilung
> meiner Arbeit ohne den Zusammenhang zu kennen.

Es ist eine potentielle Fehlerquelle.


Thomas

Re: like

Mathias Fiedler schrieb:
>>Wenn Du Dein Design tatsächlich nicht normalisieren willst dann ist
>>
>> LIKE CONCAT('%',1006_114.plz,'%')
>>
>>vermutlich die richtige Lösung, aber performancetechnisch ist das
>>eine komplette Katastrophe.
>>
>>
>=20
> Warum eigentlich ist concat so schlimm ?
> Es löst mein Problem und ich merke keinen Nachteil in der Performance=

>=20

Niemand hat gesagt, dass CONCAT für sich genommen schlimm wäre. LIKE =
mit
Linkstrunkierung ist die große Bremse. Manchmal geht es nicht ohne, abe=
r
wenn es nur nötig ist, weil mehrere gleichartige Datenelemente in einem=

Feld stehen, dann ist das bei relationalen Datenbanken in 99% aller
Fälle ein Designfehler. Vielleicht ist Deiner ja in dem einen Prozent .=
.

Es gibt Datenbanksysteme, die mit so was besser umgehen können und ihre=

Haken woanders haben, aber ich bezweifle, dass das hier die Lösung wä=
re.

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE