MySQL zwei Tabellen
wumps
- datenbank
Hallo!
Wahrscheinlich eine echt dumme Frage, aber ich versuche einen Query wie folgt:
select * from table_a as a, table_b as b where a.plz like '%b.plz%'
Der Query wird zwar ausgeführt, aber ich bekomme kein Ergebnis, obwohl es eigentlich eines geben müßte.
select * from table_a as a, table_b as b where a.plz like b.plz
funktioniert zwar, aber in table_b stehen in manchen Datensätzen im Feld plz mehrere Potleitzahlen mit Komma und Leerzeichen getrennt
Was mach ich denn falsch???
Danke,
Wumpso
Halihallo wumps
select * from table_a as a, table_b as b where a.plz like '%b.plz%'
Der Query wird zwar ausgeführt, aber ich bekomme kein Ergebnis, obwohl es eigentlich eines geben müßte.
Nein, muss es nicht. Attribut-Namen (wie b.plz) werden in Strings
_nicht_ interpoliert.
select * from table_a as a, table_b as b where a.plz like b.plz
funktioniert zwar, aber in table_b stehen in manchen Datensätzen im Feld plz mehrere Potleitzahlen mit Komma und Leerzeichen getrennt
Pfui, naja:
LIKE CONCAT('%', b.plz, '%')
http://dev.mysql.com/doc/mysql/en/String_functions.html
So _könnte_ es gehen. Performant ist es jedoch sicherlich nicht!
LIKE "%...%" - Konstruktionen sind nach Gelegenheit zu vermeiden.
Zudem: "%123%" matched auch "%12345%" also Vorsicht, wenn du auch
Schweizer-Postleitzahlen in der Datenbank stehen hast!
Zudem möchte ich meine Zweifel über den Sinn des Queries anfügen.
Was ist der Sinn des Queries, was sind die Tabellen table_a und
table_b?
Viele Grüsse
Philipp
Hi Philipp,
danke erstma
Pfui, naja:
LIKE CONCAT('%', b.plz, '%')
habe ich schon probeiert, da kriege ich 7000 Ergebnisse, kann also auch nicht stimmen
So _könnte_ es gehen. Performant ist es jedoch sicherlich nicht!
LIKE "%...%" - Konstruktionen sind nach Gelegenheit zu vermeiden.
Zudem: "%123%" matched auch "%12345%" also Vorsicht, wenn du auch
Schweizer-Postleitzahlen in der Datenbank stehen hast!
Habe auch keine schweizer Postleitzahlen
Zudem möchte ich meine Zweifel über den Sinn des Queries anfügen.
Was ist der Sinn des Queries, was sind die Tabellen table_a und
table_b?
Das ist die Tabelle geodb_locations vom GeoClass-Team www.opengeodb.org
Die ist sehr nützlich weil dort alle Längen- und Breitengrade von Orten mit Postleitzahl (und eben eventuell auch mehrere, wenn ein Ort mehrere Postleitzahlen hat) drin stehen.
Die Tablle hat ca. 14000 Einträge, und ich habe nicht vor sie zu ändern, schon aus Kompatibilitätsgründen.
Noch ne Idee?
Danke,
Wumps
yo,
habe ich schon probeiert, da kriege ich 7000 Ergebnisse, kann also auch nicht stimmen
die join bedingung fehlt, über welche die beiden tabelen miteinander verbunden sind. dann werden es auch wneiger datensätze.
Ilja
die join bedingung fehlt, über welche die beiden tabelen miteinander verbunden sind. dann werden es auch wneiger datensätze.
Ähm, was joinen?
yo,
Ähm, was joinen?
wenn du zwei oder mehrere tabellen in einer abrage verwendest, dann nennt man das einen join (verbindung). damit nun nicht jeder datensatz der einen tabelle mit jeden datensatz der anderen tabelle verbunden wird (kreuzprodukt), braucht man in alle regel für den join auch eine join-bedingung, damit nur die gewünschten datensätze beider tabellen miteinander verbunden werden. je nachdem um was für eine beziehung zwischen den tabellen existiert (1:n oder n:m), gibt es entsprechende spalten oder sogar extra beziehungstabellen.
Ilja
Ja, die Bedingung wäre doch wenn in a.plz in einer Zeile drin steht '3001' zum Beispiel, b.plz like '%30001%'
also b.plz like '%a.plz%'.
Ist doch eine gute Verbindung, oder?
wumps
Hi wumps,
antworte doch bitte mal auf meine Frage aus der direkten Antwort auf deinen Ausgangspost. Danke.
Gruss,
Stefan
Hallo Stefan,
antworte doch bitte mal auf meine Frage aus der direkten Antwort auf deinen Ausgangspost. Danke.
Hab ich gerade
wumps
yo,
na wenn das die join bedingung sein soll, warum wunderst du dich, dass dann soviele datensätze raus kommen ?
Ilja
hilfe!!!
ich will doch nur eine!
natürlich gibt es auch noch weitere wheres in dem query.
Aber in der einen Tabelle sind derzeit auch nur 3 Datensätze
wumps
Ja, die Bedingung wäre doch wenn in a.plz in einer Zeile drin steht '3001' zum Beispiel, b.plz like '%30001%'
also b.plz like '%a.plz%'.
Ist doch eine gute Verbindung, oder?
Nein!
Das ist das übelste, was Du einer Datenbank antuen kannst!
Du hast x-Tausend Datensätzen mit je einem Text-Feld und alle sollen nach der Zeichenkette durchsucht werden mit Hilfe eines %12345% *autsch*... kannst Du von ausgehen, dass es in Datenbankdimensionen EWIG dauert!!! Ist also eine miserable Lösung, zumal sie nicht das gewünschte Ergebnis liefert, denn wenn du ein Ort mit 4 PLZ hast, zb. 1234, dann findet deine Query viele Orte nämlich alle mit 1234 drin, zb. 61234, 51234, 91234, 1234, 12348 und du weißt nicht welcher der richtige ist...
Von daher, ich hab ja eine Lösung geschrieben. Nimm bitte die :o)
Gruss Stefan
Nein!
Das ist das übelste, was Du einer Datenbank antuen kannst!
Du hast x-Tausend Datensätzen mit je einem Text-Feld und alle
Jajaja, weiß schon, bin ja auch kein absoluter DB-Newbie mehr, aber ich habe die Tabelle ja nicht erfunden, und die PEAR Classe Geo macht die Abfragen auch nicht anders.
Im schlimmsten Fall muss ich mir halt tatsächlich doch noch eine neue Tabelle mit der Orts-ID und den Postleitzahlen basteln.
Ich hätte das gerne vermieden, aber in der Zeit hätte ich wahrscheinlich längst gemacht.
wumps
Zudem möchte ich meine Zweifel über den Sinn des Queries anfügen.
Was ist der Sinn des Queries, was sind die Tabellen table_a und
table_b?
Vielleicht nochmal ausführlicher, damit auch kein Zweifel über die hehre Absicht meines Unterfangens besteht:
table_a ist eine Tabelle, in der Benutzer mit Adresse und vielen Eigenschaften eingetragen sind.
table_b ist die besagte Tabelle mit den vielen Postleitzahlen und den Längen- und Breitengraden des Ortes, in der in einer Spalte teileweise eine und teilweise mehrere PPostleitzahlen (mit Komma und Leerzeichen getrennt) drinstehen.
Ich brauche nun eine Abfrage wo ich die einzelnen Eigenschaften des Benutzers abchecke, ob er angezeigt werden soll und brauche zusätzlich die Längen- und Breitengrade seiner Postleitzahl.
Das muss doch irgendwie gehen????????????
wumps
Hi,
verstehe ich Dich richtig, dass Du die Daten aus der orginalen DB von www.opengeodb.org in eine Tabelle von Dir übertragen willst? Oder was möchtest Du denn am Ende erreichen?
Gruss
Stefan
verstehe ich Dich richtig, dass Du die Daten aus der orginalen DB von www.opengeodb.org in eine Tabelle von Dir übertragen willst?
Naja, ich habe die original Tabelle geodb_locations ohne Änderungen bei mir drin. Funktioniert auch alles ganz prächtig bis auf die eine blöde Abfrage.
Aber so ein Query muss doch Standard sein? Kann das so schwierig sein????
wumps
Was willst Du denn Abfragen??
Vielleicht lässt es sich ja lösen ohne die Daten in eine neue Tabelle zu schreiben, oder wozu vergleichst du TABLA mit TABLB?
Willst Du einer Usertabelle zb die Koordinaten zur angegebene PLZ zuweisen?
Gruss Stefan
TABLA ist die besagte gedb_locations
In der TABLB steht sinngemäß drin: Ich suche im Umkreis von 100 km um meinen Wohnort eine Arbeit (oder auch eine Freundin oder sonstwas).
Jetzt kommt einer und bietet eine Arbeit an (oder sich als Freundin), sagt mit seine PLZ und ich zeige ihm diejenigen Bewerber, die dafür in Frage kommen und überhaupt so weit weg arbeiten möchten (oder so weit weg eine Freundin haben möchten oder so).
Das mit der Entfernun klappt super, nur der Abgleich der PLZ aus dem Bewerberbogen mit den PLZs aus der Datenbank klappt eben nur bei Orten, die nur eine PLZ in der Datenbank haben, eben:
select from table_a as a, table_b as where .... and a.plz = '%b.plz%'
wumps
Okay nun sind wir des Rätsels Lösung schon fast auf der Spur :o)
Wie sieht denn so ein Datensatz mit mehreren PLZ aus, könntest Du mir mal einen hier her schreiben bitte?
Gruss
Stefan
Wie sieht denn so ein Datensatz mit mehreren PLZ aus, könntest Du mir mal einen hier her schreiben bitte?
13353 6 Aalen Aalen DE BW Stuttgart Ostalbkreis NULL Aalen NULL NULL 48.8333 10.1 AA 73430,73431,73432,73433,73434
Letztes Feld sind die PLZs
Nun wendest Du mal folgendes Query an:
SELECT * FROM geodb_locations LEFT JOIN deine_tabelle ON FIND_IN_SET(deine_tabelle.plz, geodb_locations.plz)>0;
damit erhälst du alle datensätze, in denen die plz mind. einmal auftauch, also in der regel nur den einen ort, zu dem die plz gehört :o)
Gruss
Stefan
Hallo Stefan,
erstmal wieder danke für Deine Hilfsversuche, aber leider wars das auch nicht - diesmal 13981 Ergebnisse (so viele Einträge hat die geodb_locations).
damit erhälst du alle datensätze, in denen die plz mind. einmal auftauch, also in der regel nur den einen ort, zu dem die plz gehört :o)
Hier meine Abfrage:
SELECT *
FROM geodb_locations
LEFT JOIN jobsucher ON FIND_IN_SET( jobsucher.umplz, geodb_locations.plz ) > 0 LIMIT 0, 100
Ich glaube ich gebe es für heute auf, wenn Dir aber noch was einfällt, wäre ich Dir dankbar für ein Posting.
Tschüß
wumps
Hast du ICQ oder sowas?
Das kann net sein was du da hast ;o)
Irgendwas stimmt dann nciht mit deinen Daten in der DB.
Gruss Stefan
Hallo Stefan!
Shame, shame, shame, shame on me ...........
Ich hatte bei meinen Tests etwas vergessen: es gibt natürlich für die Jobsucher auch die Möglichkeit bundesweit zu suchen, und da ist dann die PLZ dummerweise "0" - und das kommt in verdammt vielen Postleitzahlen vor!!!
Deine Lösung funktioniert genauso wie auch die concat('%',a.plz,'%')-Lösung.
Das tut mir jetzt echt leid, dass ich hier so einen Terror gemacht habe, also vielen Dank auch an die anderen ....
Stefan, Dich würde ich jetzt gerne auf ein Bier oder etwas ähnlich erfreuliches einladen - vielleicht ein Kaffee?
http://www.kreativschmiede.de/kaffee/index1.html
Vielen Dank nochmal
wumps
Morgen
Deine Lösung funktioniert genauso wie auch die concat('%',a.plz,'%')-Lösung.
"Genauso" würde ich nicht sagen! Die Ergebnismenge bei concat('%',a.plz,'%') kann wie gesagt auch andere PLZ beinhalten, rate ich Dir dringend von ab!! *Empfehlung*
Bei der angegebenen Lösung wird wirklich nach dem exakten Vorkommen von der PLZ in dem kommagetrennten Textfeld gesucht. Wenn Du dabei also nach 1234 suchst, wird auch nur nach 1234 gesucht und nicht etwa nach 12345 oder 41234. Ich würde mir das gut überlegen. Besonders führt das vielleicht später mal zu einem Fehler, an den sich dann keiner mehr erinnern wird. Also möglichst von Vorneherein vermeiden :o)
Stefan, Dich würde ich jetzt gerne auf ein Bier oder etwas ähnlich erfreuliches einladen - vielleicht ein Kaffee?
http://www.kreativschmiede.de/kaffee/index1.html
Danke für den Kaffee :o)
Viele Grüße
Stefan
Guten Morgen Stefan,
ich habe mir das ganze nochmal überlegt - wie Du schon sagst ist es [ein ein bisschen] doof, mit solchen Textfeldern zu arbeiten und danach als String-Muster zu suchen.
Es geht zwar derzeit noch hinreichend schnell, aber sollte die Site ein Erfolg werden, könnte es doch passsieren, dass die vielen Queries den Server in die Knie zwingen und die Ergebnisse ewig dauern (er muss ja auch für die Entfernungsberechnung schon ordentlich rechnen).
Ich werde also eine Tabelle erstellen mit einer eindeutigen PLZ und deren Koordinaten (ich schreib ein Progämmchen, das die Daten aus der geodb_locations übernimmt und bei PLZs, die mehreren Orten zugeordnet sind - was es ja auch gibt - nehme ich eben den Mittelwert der jeweiligen Koordinaten), also (id), PLZ, lange, breite.
Ist der Ableich viel langsamer, wenn ich für das PLZ-Feld dann ein Char oder Varchar nehme (manche PLZs beginnen ja mit "0")? Theoretisch könnte ich ja (immer vorausgesetzt wir bleiben in Deutschland) auch ein Int-Feld nehmen, was wahrscheinlich schneller zu vergleichen wäre, oder?
Viele Grüße
wumps