Spaltenwerte zweier Tabellen vergleichen; dabei eine vom Typ BLOB

[HendriX]

@akretschmer - Ok, ich denke Du kennst Dich damit aus, und ich glaube Dir das... Werde mich diesbezüglich noch weiterbilden..

Nochmals abschließend die Frage: Es gibt also definitiv keine valide (einfache) SQL-Abfrage-Methode für diese DB-Konstellation mit BLOB-Feld..!?!

 

[HendriX]

SELECT    p.id
FROM    products p
WHERE EXISTS (    SELECT    1
                FROM    member m
                WHERE    m.user_id = thisUser
                AND        m.fav_cats LIKE ( '%"' + p.cat_id + '"%' ) )

So in etwa stell ich mir das in SQL vor...

Danke für Deinen Vorschlag / Eure Vorschläge! Klingt gut und verständlich! ...geht aber so (zumindest in meinem aktuellen Framework) nicht... Bis auf weiteres werde ich wohl zunächst bei meiner Lösung bleiben, da die —wie gesagt— ja scheinbar fehlerfrei unter MySQL läuft...

Wenn es dann in die finale Phase geht, werde ich auf jeden Fall noch einmal einen Fachmann drauf schauen lassen, um dann ggf. die DB-Architektur zu modifizieren...

 

[akretschmer]

@akretschmer - Ok, ich denke Du kennst Dich damit aus, und ich glaube Dir das... Werde mich diesbezüglich noch weiterbilden..

Nochmals abschließend die Frage: Es gibt also definitiv keine valide (einfache) SQL-Abfrage-Methode für diese DB-Konstellation mit BLOB-Feld..!?!

BLOB kann groß werden, kann Zeichenketten enthalten, mit denen Du nicht rechnest. Für Deine WHERE-Conditions bekommst Du keine Index-Unterstützung. Konstrukte wie Deine führen in hohem Tempo geradlinig an die Betonwand.

 

[HendriX]

BLOB kann groß werden, kann Zeichenketten enthalten, mit denen Du nicht rechnest. Für Deine WHERE-Conditions bekommst Du keine Index-Unterstützung. Konstrukte wie Deine führen in hohem Tempo geradlinig an die Betonwand.

Vom Prinzip stimmt das sicherlich, was Du sagst. Doch in diesem Fall steht für das BLOB-Feld fav_cats ja nur eine begrenzte, genau von mir definierte Menge an Auswahl-Optionen zur Verfügung, die das CM-System da irgendwie (aber ja wohl immer gleich..!) rein-"serialisiert"... Da sehe ich jetzt also nicht die Gefahr, dass da irgendwie/-wann außerordentliche Zeichen(-Ketten) auftauchen...

Ich hätte die Sache auch gerne normalisiert! Doch das hätte dann alles einen längeren Rattenschwanz, das alles umzusetzen. Hier geht es v.a. auch um einen geeigneten Frontend-Editing-Support, welcher in der Extension, der ich mich bediene, noch nicht implementiert wurde. Daher weiche ich hier über den Core des Systems aus, zu dem eben eine member-Verwaltung mit FE-Editing gehört. Und dort sind an diesen Stellen (Mehrfach-Auswahl-Felder) die BOLBs schein's Standard.. was da wahrscheinlich von vorne herein nicht ganz optimal konzipiert worden ist..

 

[akretschmer]

Ich hätte die Sache auch gerne normalisiert! Doch das hätte dann alles einen längeren Rattenschwanz, das alles umzusetzen. Hier geht es v.a. auch um einen geeigneten Frontend-Editing-Support, welcher in der Extension, der ich mich bediene, noch nicht implementiert wurde. Daher weiche ich hier über den Core des Systems aus, zu dem eben eine member-Verwaltung mit FE-Editing gehört. Und dort sind an diesen Stellen die BOLBs schein's Standard.. was da wahrscheinlich von vorne herein nicht ganz optimal konzipiert worden ist..

Mag alles sein. Es gibt übrigens Datenbanken, die für sowas sogar passende Datentypen wie JSON und HSTORE haben, hint, hint ...

 

[HendriX]

Ja, wohl wahr: hint, hint... : o )

Da ich aber nur ein "einfacher" Web-Designer und Frontend-Entwickler bin, der sich in ein konkretes CMS (mit vielen anderen, meiner Meinung nach sehr wertvollen Vorteilen) verschossen hat, ist das jetzt so ne Frage, ob das "allein" jetzt ein (zwingender) Grund wäre sich nach einem anderen Framework umzuschauen...!?

 

[HendriX]

Hier mal ein Zitat zu dem Thema BLOB-Lösungen aus dem Forum "meines" CMS:

Naja, es gibt halt zwei Varianten Tabellen in n:m zu verbinden.

Normalisiert würde heißen über eine dritte Tabelle, die Abfragen würden dann per Join über drei Tabellen gehen.

In [CM-System] hat man sich damals entschlossen das nicht zu tun und stattdessen über BOLBs mit serialisierten Arrays drin. (was übrigens keine Erfindung von [CM-System] ist)

Vielleicht war man sich damals noch nicht bewusst, dass es n:m Beziehungen in großer Menge geben könnte wo sich dritte Tabellen lohnen würden.

Ändern ließe sich das erst wenn ein großer Framework-Bruch vonstatten geht, in dem sowieso alles inkompatibel wird bzw. man auf Abwärtskompatibilität keine Rücksicht nehmen muss...

 

[akretschmer]

Hier mal ein Zitat zu dem Thema BLOB-Lösungen aus dem Forum "meines" CMS:

Contao. Ich will es nicht weiter kommentieren.

 

[HendriX]

Jetzt hast Du es verraten... ; o ) Wollte das System hier jetzt nicht denunzieren...

Aber, wo wir es jetzt schon wissen: Was ist Deine Meinung zu dem System? Welches ist Dein Favorit?

 

[akretschmer]

Jetzt hast Du es verraten... ; o ) Wollte das System hier jetzt nicht denunzieren...

Nein, verraten hast Du es. Hast Du schon mal was von Google gehört?

Aber, wo wir es jetzt schon wissen: Was ist Deine Meinung zu dem System? Welches ist Dein Favorit?

Da fragst Du den falschen.

Andreas

 

[HendriX]

Contao. Ich will es nicht weiter kommentieren.

Na gut, aber was meintest Du dann mit dieser Aussage? Die klingt so wie: "Kenne ich, ist schlimm/schlecht..." Oder wie darf man das verstehen?

 

[akretschmer]

Na gut, aber was meintest Du dann mit dieser Aussage? Die klingt so wie: "Kenne ich, ist schlimm/schlecht..." Oder wie darf man das verstehen?

Ich wollt die Begründung da nicht weiter kommentieren, nicht das CMS.

 

[HendriX]

Ach so! : o )

DANKE auf jeden Fall für Deine Ratschläge und Hilfe - bis dato...