mixmastertobsi: mysql dubletten JOIN

SELF-Forum

mysql dubletten JOIN

mixmastertobsi (Versionen)
– Informationen zu den Bewertungsregeln

Hallo,

ich möchte mit MySQL dubletten finden, allerdings über mehrere Tabellen hinweg.

Beispiel:

Tabelle Artikel-Attribute

ID|Artikel 1 |Tisch 80x160 rot 2 |Tisch 80x160 rot

Tabelle Attribute

Attribut | Artikel-ID | value 1 | 1 | 80x160 cm 2 | 1 | rot 1 | 2 | 80x160 cm 2 | 2 | rot

Meine Idee war, das mit Group_Concat zu lösen und zu prüfen, ob es noch ein Artikel mit den selben Attributen gibt, allerdings ist mir dies nicht ganz gelungen.

SELECT

(SELECT GROUP_CONCAT(attribut.value) FROM attribut WHERE attribut.artikel-id=Artikel-Attribute.id) as attribut1,
(SELECT GROUP_CONCAT(attribut.value) FROM attribut  as attribut_vergleich WHERE attribut_vergleich.artikel-id!=Artikel-Attribute.id) as attribut2,

FROM `Artikel-Attribute` 

GROUP BY Artikel-Attribute.id
Beitrag melden
–
Informationen zu den Bewertungsregeln

  1. mysql dubletten JOIN

    Rolf b
    – Informationen zu den Bewertungsregeln

    Irgendwie habe ich gerade ein déjà-vu, als ob ich dieses Thema schon mal gesehen hätte... Aber ich find's nicht wieder. "langsame SQL Abfrage" von tobi85? War's nicht ganz. Egal.

    Ich verstehe dein Datenmodell nicht. Ich hätte eine Tabelle "Artikel" erwartet, worin "Tisch" steht, und der über die Attribute-Tabelle näher spezifiziert wird. Wenn Du doch in der "Artikel-Attribute" Tabelle bereits die Artikelbeschreibung inclusive der Attribute stehen hast, warum musst Du dann noch die Attribute-Tabelle dazu joinen?

    Da reicht doch

    SELECT a1.ID, a2.ID, a1.Artikel
FROM artikel-attribute a1 JOIN artikel-attribute a2 ON a1.Artikel = a2.Artikel AND a1.ID <> a2.ID

    Wenn Du Dich auf die Artikelbeschreibung in Artikel-Attribute nicht verlassen kannst/willst, dann hast Du bei einem reinen Attributevergleich das Problem, dass Du ggf. Äpfel mit Birnen vergleichst. Ein "Tisch 80x120 rot" und eine "Kuscheldecke 80x120 rot" haben die gleichen Attribute, sind aber keine Dubletten.

    Denk nochmal über dein Datenmodell nach; es ist allerdings nicht trivial, es gleichzeitig normalisiert und performant hinzugebekommen.

    Wenn ich das bauen sollte, würde ich über Tabellen lösen wie diese:

    Artikel (siehe unten zur Redundanz-Spalte "rBeschreibung")

    ArtikelID|TypID|Bestand|X|Y|rBeschreibung 1|1|7|dings|bums|Tisch 80x120cm rot 2|1|2|hui|bu|Tisch 80x120cm blau 3|2|3|bla|tröt|Kuscheldecke 80x120cm rot

    ArtikelTyp

    |TypID|TypBezeichnung |1|Tisch |2|Kuscheldecke

    Attribut

    |AttrID|AttrTypID|AttrWert |1|1|80x120cm |2|1|70x190cm |3|2|rot |4|2|blau

    AttributTyp

    |AttrTypId|AttrName |1|Größe |2|Farbe

    ArtikelAttribut

    |ArtikelID|AttrID |1|1 |1|3 |2|1 |2|4 |3|1 |3|3

    Nach der reinen Lehre gebaut kann das allerdings relativ langsam bei der Abfrage für Anzeige werden, für solche Zwecke musst Du überlegen, was Du cachen oder gezielt redundant speichern kannst. Jede Redundanz will allerdings gepflegt werden, was Aufwand im Programm bedeutet. Die oben gezeigte rBeschreibung Spalte ist so eine Redundanz - aber jede Änderung im Artikel-Editor oder in den Wertebereichtabellen führt dazu, dass Du diese Spalte updaten musst.

    Der Vorteil ist aber, dass Du eine saubere Datengrundlage für Abfragen hast. Ich muss jetzt weg, aber werde mich mit Abfragevorschlägen nochmal melden.

    Rolf

    Beitrag melden
    –
    Informationen zu den Bewertungsregeln