SQL LIKE
doni
- datenbank
Hallo zusammen
Ich habe die Tabellen 'shirts' und 'products'.
Nun möchte ich eine solche Abfrage machen:
SELECT products.product_ID, products.shirt_ID, shirts.shirt_ID WHERE products.shirt_ID LIKE '%shirts.shirt_ID%'
Nun mein Problem ist, dass er shirts.shirt_ID als einen String ansieht und nicht den Inhalt der zelle holt. Ist das irgendwie möglich zu realisieren?
Habs auch mit
... LIKE %shirts.shirt_ID%
... LIKE shirts.shirt_ID
probiert. Bringt beides auch nix...
Weiss jemand von euch weiter?
Gruss
doni
Hi doni,
SELECT products.product_ID, products.shirt_ID, shirts.shirt_ID WHERE products.shirt_ID LIKE '%shirts.shirt_ID%'
Nun mein Problem ist, dass er shirts.shirt_ID als einen String ansieht und nicht den Inhalt der zelle holt. Ist das irgendwie möglich zu realisieren?
Nun im Allgemeinen ist eine ID ein Integer, warum nimmst du nicht den Gleichheitsoperator? Dein Konstrukt sollte zwar auch funktionieren, ist aber nicht performant und überhaupt einfach nicht schön (Wo sind die Argumente, es gbt bestimmt genügend, aber sie haben gerade alle Pause in meinem Kopf)
Davon mal abgesehen, weiß der Computer nicht, aus welchen Tabellen er die Daten holen soll. Wenn du ihm das noch sagst, klappt es bestimmt auch.
Beschäftige Dich mit join [1]
Viel Spaß
ciao
romy
[1] Ach ja, ich bin jetzt mal von MySQL ausgegangen, da du dein DMS nicht verrätst.
Hallo Romy...
Sorry ich habe nur schnell einen Teil des querys abgeschrieben. Aus welchen Datenbanken er es nehmen soll, ist schon drin.
das ganze wäre:
SELECT products.product_ID, products.shirt_ID, products.product_name, products.product_picurl, products.product_description, shirts.shirt_type, shirts.shirt_color, shirts.shirt_sex, shirts.shirt_price, sujets.sujet_ID, sujets.sujet_name, sujets.sujet_picurl, sujets.sujet_color, sujets.sujet_price FROM products, shirts, sujets WHERE shirts.shirt_ID LIKE products.shirt_ID AND products.sujet_ID = sujets.sujet_ID AND products.product_ID = '$productid' LIMIT 1
Mein Problem ist folgendes:
In der Tabelle 'products' im Feld 'shirt_ID' sollte sowas stehen:
00027,00024,00011
Also verschiedene Werte, kommagetrennt. Nun möchte ich schauen, ob in products.shirt_ID ein wert vorkommt, der in shirts.shirt_ID (dort steht nur eine zahl) ist.
Also
ist in products.shirt_ID der wert aus shirts.shirt_ID enthalten?
Meine Frage ist mehr oder weniger ob es möglich ist, ein LIKE '%datenbankfeldname%' auszuführen (und wenn ja, wie?) oder ob man LIKE nur einen string zuweisen kann...
danke für eure Hilfe!
doni
Hi,
In der Tabelle 'products' im Feld 'shirt_ID' sollte sowas stehen:
00027,00024,00011
Also verschiedene Werte,
falsch.
In einem Datenbank-Feld steht immer nur *ein* Wert. Dieser ist atomar. Wenn Du nun meinst, da seien mehrere Werte, so bedeutet das, dass das DB-Layout schwerwiegend fehlerhaft ist. Normalisiere es.
Cheatah
yo,
falsch.
In einem Datenbank-Feld steht immer nur *ein* Wert. Dieser ist atomar. Wenn Du nun meinst, da seien mehrere Werte, so bedeutet das, dass das DB-Layout schwerwiegend fehlerhaft ist. Normalisiere es.
falsch
atomarität hat nichts mit *ein* wert zu tun. Würde dort immer nur ein wert stehen, bräuchten man es bezüglich der atomariät ja nicht mehr zu normalisieren.
Ilja
hehe
mir kommt gleich das kotzen wenn ich normalisieren hör ;-)
mein DBMS ist übrigens MySQL ;)
Ich werd euch meine Tabellen mal posten :)
Gruss
doni
Hi doni,
In der Tabelle 'products' im Feld 'shirt_ID' sollte sowas stehen:
00027,00024,00011
Also verschiedene Werte, kommagetrennt. Nun möchte ich schauen, ob in products.shirt_ID ein wert vorkommt, der in shirts.shirt_ID (dort steht nur eine zahl) ist.
Cheatah hat absolut recht, deine Datenbankaufbau ist nicht optimal, wenn du tatsächlich mehrere Werte durch Komma getrennt in den einzelnen Feldern hast. Poste doch mal den Aufbau beider Tabellen, vielleicht kann man ja helfen, bei der Optimierung.
Ach ja, hier findest du den Operator "IN", der dir dabei helfen sollte, es so umzusetzen, wie du es momentan möchtest.
Ich rate dir trotzdem noch mal die Überarbeitung deines Datenbankaufbaus.
ciao
romy
yo,
Ach ja, hier findest du den Operator "IN", der dir dabei helfen sollte, es so umzusetzen, wie du es momentan möchtest.
Ich rate dir trotzdem noch mal die Überarbeitung deines Datenbankaufbaus.
ich kann im moment nicht erkennen, wie der IN operator ihm helfen sollte, da der Operator die werte innerhalb eines feldes nicht auftrennen kann.
Ilja
hi,
Ach ja, hier findest du den Operator "IN", der dir dabei helfen sollte, es so umzusetzen, wie du es momentan möchtest.
ich kann im moment nicht erkennen, wie der IN operator ihm helfen sollte, da der Operator die werte innerhalb eines feldes nicht auftrennen kann.
Nein, aber die Stringfunktion FIND_IN_SET() kann.
Ich rate dir trotzdem noch mal die Überarbeitung deines Datenbankaufbaus.
Das bleibt unbestritten.
gruß,
wahsaga
yo,
Nein, aber die Stringfunktion FIND_IN_SET() kann.
ich würde nicht unbedinkt diese funktion einsetzen, da das dbms einen aufwänderigen vergleich anstellen muss, als wenn man ihn konkretere angaben machen kann, wo sich die gesuchten angaben im string verstecken. aber ob das überhaupt geht, muss noch beantwortet werden.
Ilja
hi,
ich würde nicht unbedinkt diese funktion einsetzen, da das dbms einen aufwänderigen vergleich anstellen muss, als wenn man ihn konkretere angaben machen kann, wo sich die gesuchten angaben im string verstecken. aber ob das überhaupt geht, muss noch beantwortet werden.
An Hand des gebrachten Beispiels habe ich da Zweifel :-)
gruß,
wahsaga
yo,
An Hand des gebrachten Beispiels habe ich da Zweifel :-)
die werte haben scheinbar eine konstante länge und befinden sich an fest definierten orten. sieht doch gut aus.
Ilja
hi,
die werte haben scheinbar eine konstante länge und befinden sich an fest definierten orten. sieht doch gut aus.
Und welche Suchmöglichkeit mit besserer Performance schwebt dir dann diesbezüglich vor?
gruß,
wahsaga
yo,
Und welche Suchmöglichkeit mit besserer Performance schwebt dir dann diesbezüglich vor?
die funktion substr() und dann den wert mit dem '=' Operator als Join Bedingung vergleichen und das ganze als OR miteinander verbunden.
Ilja
Hallo,
Warum sollte man krampfhaft versuchen, noch etwas aus dem verkorksten Datenbankdesign zu holen, wenn sowieso klar ist, dass es nur einen vernünftigen Weg gibt, nämlich das betreffende Feld in eine separate Tabelle auszulagern?
Ich versteh das nicht. Eure Diskussion hat den Anschein, als ob es dann doch noch alternative Problemlösungsstrategien gibt, die Sinn machen. Da dem aber nicht so ist, sollte man dem OP nicht noch weiter auf dumme Gedanken bringen.
Grüße
Klaus
yo,
Warum sollte man krampfhaft versuchen, noch etwas aus dem verkorksten Datenbankdesign zu holen, wenn sowieso klar ist, dass es nur einen vernünftigen Weg gibt, nämlich das betreffende Feld in eine separate Tabelle auszulagern?
jeder hier hat ihm nun nahe gelegt, dass design zu ändern. aber wir kennen auch nicht seine situation. es gibt manchmal zwingende gründe, zum beispiel weil er die strukturen nicht verändern darf. besonders früher in der DV war das ein schwieriges thema. wichtig ist nicht, was wir denken, sondern was er für die beste lösung hält.
Ilja
Hi Klaus,
Ich versteh das nicht. Eure Diskussion hat den Anschein, als ob es dann doch noch alternative Problemlösungsstrategien gibt, die Sinn machen. Da dem aber nicht so ist, sollte man dem OP nicht noch weiter auf dumme Gedanken bringen.
Ja und Nein, letztendlich ist es des Posters Entscheidung, welche Variante er wählt, genügend Argumente pro und contra hat er ja. Ausserdem kommt diese Disskusion auch zu Stande, da der UP sich bisher nicht noch mal gemeldet hat um zu sagen, welche Situation bei ihm vorliegt. Dadurch gibt es keinen spezifischen Rat, sondern eben einen Allgemeinen. Ohne seinen Input kann man ja nur raten, was sein Problem ist.
Ich glaube einfach an Entwickler mit Verstand, die gute von schlechten Lösungen durchaus zu unterscheiden wissen. Einzig Lösungen, welche offensichtliche Probleme für das Allgemeinwohl darstellen könnten, würde ich nicht rausgeben. Soviele dürften das nicht sein ;) Obwohl wir so einen Thread durchaus auch haben, das finde ich viel kritischer.
ciao
romy
Hallo Romy,
Ach ja, hier findest du den Operator "IN", der dir dabei helfen sollte, es so umzusetzen, wie du es momentan möchtest.
Nö, siehe Ilja. doni könnte mit dem Verkettungsoperator oder der Verkettungsfunktion seines uns immer noch unbekannten DBMS ein LIKE-Statement zusammenbasteln.
In Transact-SQL (MS SQL-Server) sollte z.B.
WHERE products.shirt_ID LIKE '%' + shirts.shirt_ID + '%'
einen Würgaround für donis Problem darstellen.
Ich rate dir trotzdem noch mal die Überarbeitung deines Datenbankaufbaus.
Ja. Ganz dringend. Alles andere ist Mist, auch mein Vorschlag weiter oben :-)
Freundliche Grüße
Vinzenz
yo,
In der Tabelle 'products' im Feld 'shirt_ID' sollte sowas stehen:
00027,00024,00011
in einem punkt hat Cheatah recht, diese lösung führt zu eben solchen problemen, wie du sie gerade hast. entweder du schreibst in der spalte für shirt_ID immer nur eine referenz zu einen datensatz in der anderen tabelle (fremdschlüssel).
falls dies aus irgendeinen grund nicht möglich ist, dann könnte man unter bestimmten vorraussetzungen etwas "basteln". wichtig ist dabei, dass die nummern einen feste länge haben und die anzahl immer gleich ist, bzw, die maximale anzahl der schlüssel.
Ilja