Hallo Klaus1, > Wie kann ich diese nun so verknüpfen, dass ich in der Ergebnisliste auch der Artikel, der mehrfach vorkommt, mehrfach auftaucht? Nicht mit SQL. Der SET Datentyp von MYSQL ist für sowas verlockend, aber ein find_in_set in einer JOIN-Bedingung ist ein ekelhafter Köter, der nur darauf wartet, dass deine Anwendung wächst, um Dir dann mit Begeisterung in den A...llerwertesten zu beißen. Wie Raketenwilli sagte: find_in_set ist nicht indizierbar. MYSQL muss also für jede Row in Tabelle 1 einen Full Table Scan von Tabelle 2 machen, um den Join herzustellen. Bei 419 Artikeln wird er Tabelle 2 wohl noch komplett im Cache-RAM halten können. Aber genau da kann ein Artikel mehr in Tabelle 2 den Unterschied zwischen "geht noch im Cache" und "jetzt cache ich das nicht mehr komplett" ausmachen, und dann bricht die Performance massiv ein. Der Set-Datentyp ist einer der vielen Designfehler von MYSQL. Statt Dich zur Normalisierung anzuhalten, bietet es Dir Datentypen an, die eine korrekte DB-Modellierung geradezu als dumm erscheinen lassen. Warum sollte man eine Artikelnummernliste in eine Tabelle auslagern, wenn man sie doch ganz praktisch als kommaseparierte Liste in einen String stecken kann und die DB auch noch Funktionen bietet, darin herumstochern zu können. Aber sobald die Wünsche wachsen, ist es dann vorbei. Ein **Set** ist definiert als eine Datenstruktur, die keine doppelten Einträge kennt. Und damit ist find_in_set am Ende. Wenn Du bei der CSV Liste bleiben willst, musst Du auf den LEFT JOIN verzichten. In PHP kannst Du die Artikelliste nehmen und sie als Werteliste in eine IN-Klausel eintragen. Damit holst Du Dir die benötigten Artikel aus der DB. Wobei man das auch noch mal mit EXPLAIN überprüfen müsste, es kann nämlich sein, dass ein IN ebenfalls einen Tablescan macht. Danach EXPLODEst Du die Artikelliste und gibst für jede Artikelnummer den zugehörigen Satz aus. Ist eine Nummer drölfmal drin, wird der Satz dann auch drölf mal ausgegeben. Ist das empfehlenswertes DB Design? Nein! _Rolf_ -- sumpsi - posui - obstruxi

Hallo Klaus1, > Wie kann ich diese nun so verknüpfen, dass ich in der Ergebnisliste auch der Artikel, der mehrfach vorkommt, mehrfach auftaucht? Nicht mit SQL. Der SET Datentyp von MYSQL ist für sowas verlockend, aber ein find_in_set in einer JOIN-Bedingung ist ein ekelhafter Köter, der nur darauf wartet, dass deine Anwendung wächst, um Dir dann mit Begeisterung in den A...llerwertesten zu beißen. Wie Raketenwilli sagte: find_in_set ist nicht indizierbar. MYSQL muss also für jede Row in Tabelle 1 einen Full Table Scan von Tabelle 2 machen, um den Join herzustellen. Bei 419 Artikeln wird er Tabelle 2 wohl noch komplett im Cache-RAM halten können. Aber genau da kann ein Artikel mehr in Tabelle 2 den Unterschied zwischen "geht noch im Cache" und "jetzt cache ich das nicht mehr komplett" ausmachen, und dann bricht die Performance massiv ein. Der Set-Datentyp ist einer der vielen Designfehler von MYSQL. Statt Dich zur Normalisierung anzuhalten, bietet es Dir Datentypen an, die eine korrekte DB-Modellierung geradezu als dumm erscheinen lassen. Warum sollte man eine Artikelnummernliste in eine Tabelle auslagern, wenn man sie doch ganz praktisch als kommaseparierte Liste in einen String stecken kann und die DB auch noch Funktionen bietet, darin herumstochern zu können. Aber sobald die Wünsche wachsen, ist es dann vorbei. Ein **Set** ist definiert als eine Datenstruktur, die keine doppelten Einträge kennt. Und damit ist find_in_set am Ende. Wenn Du bei der CSV Liste bleiben willst, musst Du auf den LEFT JOIN verzichten. In PHP kannst Du die Artikelliste mit EXPLODE auseinandernehmen und dann die benötigten Sätze mit einzelnen Abfragen aus der Tabelle 2 holen. Bei der Gelegenkeit kannst Du dann auch zählen, welcher Artikel wie oft vorkommt. Diesen sauren Apfel wirst Du wohl knabbern müssen - oder Dich immer wieder mit Datenbankproblemen herumschlagen. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Klaus1, > Wie kann ich diese nun so verknüpfen, dass ich in der Ergebnisliste auch der Artikel, der mehrfach vorkommt, mehrfach auftaucht? Nicht mit SQL. Der SET Datentyp von MYSQL ist für sowas verlockend, aber ein find_in_set in einer JOIN-Bedingung ist ein ekelhafter Köter, der nur darauf wartet, dass deine Anwendung wächst, um Dir dann mit Begeisterung in den A...llerwertesten zu beißen. Wie Raketenwilli sagte: find_in_set ist nicht indizierbar. MYSQL muss also für jede Row in Tabelle 1 einen Full Table Scan von Tabelle 2 machen, um den Join herzustellen. Bei 419 Artikeln wird er Tabelle 2 wohl noch komplett im Cache-RAM halten können. Aber genau da kann ein Artikel mehr in Tabelle 2 den Unterschied zwischen "geht noch im Cache" und "jetzt cache ich das nicht mehr komplett" ausmachen, und dann bricht die Performance massiv ein. Der Set-Datentyp ist einer der vielen Designfehler von MYSQL. Statt Dich zur Normalisierung anzuhalten, bietet es Dir Datentypen an, die eine korrekte DB-Modellierung geradezu als dumm erscheinen lassen. Warum sollte man eine Artikelnummernliste in eine Tabelle auslagern, wenn man sie doch ganz praktisch als kommaseparierte Liste in einen String stecken kann und die DB auch noch Funktionen bietet, darin herumstochern zu können. Aber sobald die Wünsche wachsen, ist es dann vorbei. Ein **Set** ist definiert als eine Datenstruktur, die keine doppelten Einträge kennt. Und damit ist find_in_set am Ende. Diesen sauren Apfel wirst Du wohl knabbern müssen - oder Dich immer wieder mit Datenbankproblemen herumschlagen. _Rolf_ -- sumpsi - posui - obstruxi