[Erledigt] EAV Model Join Problem

kaukat · 06.01.2011, 16:51

Hallo zusammen,

ich bin gerade dabei Teile einer existierenden DB in das EAV-Model umzuwandeln und ärgere mich schon seit Tagen mit den ewigst langen JOIN Abfragen rum. Meine Tabellenstruktur sieht aus wie die Grafik auf dieser Seite unter dem Punkt "Speicherung unterschiedlicher Datentypen"
http://www.informave.org/de/database...esign_eav.html

Weiters wären dort auch kleine Beispielauszüge aufgelistet, mit denen man in Kombination mit der Grafik jedoch leider nichts anfangen kann (zumindest ich nicht).

Ich war jetzt mal so weit, dass ich diese Query absende (ich will 3 Werte - Produkt-ID, Preis und Bild):

PHP-Code:

  select 

p.products_id, 

pprice.value products_price, 

pimage.value products_image 

from products_entity p 

inner join eav_attribute as eavattr on (p.entity_id = eavattr.entity_id) 

inner join attribute as attr on (eavattr.attribute_id = attr.attribute_id) 

left join product_value_decimal as pprice on (eavattr.eav_attribute_id = pprice.eav_attribute_id) 

left join product_value_varchar as pimage on (eavattr.eav_attribute_id = pimage.eav_attribute_id) 

where eavattr.entity_id = '102' and eavattr.attribute_id = attr.attribute_id and attr.attribute_name = 'price' 

or eavattr.entity_id = '102' and eavattr.attribute_id = attr.attribute_id and attr.attribute_name = 'image'

durch den INNER JOIN von products_entity zu eav_attribute hab ich aber nun das Problem, dass ich für x Attribute auch x Ergebniszeilen bekomme, wobei in jeder Ergebniszeile alle Attribute bis auf eines NULL haben:

products_id , products_price, products_image
102, NULL, 31U1Kc9aUHL._SL500_AA300_.jpg
102 ,88.7850, NULL

... ist mir durch diese Abfrage auch ganz klar warum und wieso, nur weiß jemand von euch einen einfacheren Weg die Attribute in einer Zeile gesammelt zu erhalten bzw. gibt es eine Möglichkeit alle Zeilen nach der ID so zu gruppieren, dass alle gewünschten Attribute in einer Zeile stehen wie z.B.

products_id , products_price, products_image
102, 88.7850, 31U1Kc9aUHL._SL500_AA300_.jpg

Falls euch die Grafik in Kombination mit meiner Query durch die unterschiedlichen Bezeichnungen verwirrt, bastel ich selbst noch schnell ein UML zusammen.

zZ hab ichs bei einfacheren Abfragen mal ganz hässlich gelöst und alles im Nachhinein in Arrays abgespeichert mit IF-Abfragen ob der Wert nicht NULL ist, aber das kann es auch nicht sein, komplexere Abfragen sind damit nicht zu bewältigen..

ich hoffe ihr könnt mir hier weiterhelfen!

erc · 06.01.2011, 18:00

Erklär dich mal... was soll das werden wenns fertig ist? Ein Leitfaden alá "Wie verwende ich ein RDBMS falsch, richtig falsch"

PS: Für das gewünschte Ergebniss brauchst du noch 2 Joins. Bei der Struktur brauchst du für jeden Wert den du auslesen willst 3 Joins wenn der Datentyp bekannt ist, 5 Joins wenn er nicht bekannt ist.

kaukat · 06.01.2011, 18:21

Jein, das EAV-Model hat genauso auch seine Vorteile in gewissen Bereichen wie z.B. bei E-Commerce Systemen. Magento z.B. setzt es schon seit längerem ein.
Mein Fall hier bezieht sich auf ein Uni-Projekt in dem ich versch. DB-Modelle für E-Commerce Systeme untersuche, natürlich auch falsche Modelle inbegriffen

Hm.. auf welche Tabellen beziehen sich die 2 weiteren Joins? Könntest du mir bitte ein Beispiel für die 3 bzw. 5 Joins geben?

erc · 06.01.2011, 20:45

Zitat:

Zitat von kaukat

Jein, das EAV-Model hat genauso auch seine Vorteile in gewissen Bereichen wie z.B. bei E-Commerce Systemen. Magento z.B. setzt es schon seit längerem ein.

Ich kenn die Vor- und Nachteile, ich bin mir nur nicht sicher ob du sie kennst. Magento ist auch gleich ein schönes Beispiel dafür. Frag doch mal in die Runde was den Leuten mit als erstes zu Magento durch den Kopf geht. Lagsammmmm².... und 3 mal darfst du raten was dafür der Hauptgrund ist bzw. war. Mittlerweile haben Sie ein Cache eingebaut der ein paar EAV Strukturen on the fly in ein normales Model überführt.

Zitat:

Zitat von kaukat

Hm.. auf welche Tabellen beziehen sich die 2 weiteren Joins? Könntest du mir bitte ein Beispiel für die 3 bzw. 5 Joins geben?

Stark vereinfacht...

PHP-Code:

  SELECT

product_id,

product_value_price.value AS price,

product_value_image.value AS image

FROM

product JOIN 

(

  eav_attribute AS eav_attribute_price JOIN

  attribute AS atrribute_price JOIN

  product_value AS product_value_price

) JOIN

(

  eav_attribute AS eav_attribute_image JOIN

  attribute AS atrribute_image JOIN

  product_value AS product_value_image

)

Die Klammern sind nur zum besseren Verständnis und können weggelassen werden.

kaukat · 06.01.2011, 22:21

Super, danke, klappt einwandfrei!

Es war mir bei diesem Modell schon von Anfang an klar dass das ganze performancemäßig ziemlich in die Knie gehen wird, aber ansehen muss ichs mir im Rahmen meines Projekts trotzdem.. dass das auch Magento's Laster ist ist mir natürlich auch klar, Cache kommt bei mir in Schritt 2 auch noch dazu, in Schritt 3 geh ich dann weiter zu Key-Value Stores um dann evaluieren zu können was wie wo usw. um mein Paper schön füllen zu können, auch wenn ich letztendlich zu dem Ergebnis kommen könnte dass das alles wenig Sinn hat.

Nochmals danke für deine Hilfe, alleine hätt ich dafür wohl noch eine ganze Weile gebraucht!

xm22 · 07.01.2011, 17:24

Zugegeben ist Magento ziemlich langsam - Aber nicht aufgrund seiner Datenstruktur. Das Problem ist das Auslesen der Daten mittels einem riesigen OOP-Overhead. In unserem Unternehmen haben wir das in native SQL-Statements umgewandelt und es hat einen enormen Geschwindigkeitszuwachs gebracht. EAV an sich ist in meinen Augen ein super Prinzip.

SebboKleine · 06.07.2011, 10:35

Auch wenn der Thread schon etwas älter ist. Ich bin grad drüber gestolpert und möchte kurz was zu sagen.

Magento hat zwei Probleme: EAV-Modell UND sein OOP-Overhead. Das erste haben sie in neueren Versionen durch "flat-tables" gelindert, das zweite versucht durch caching in den Griff zu bekommen.
Richtig kritisch wird es erst bei höheren Produkt-Mengen. Bei 100 Produkte und 30 Attributen ist EAV toll. Und auch der OOP-Overhead nicht das Problem.

Aber wehe du hast 150.000 Produkte und 400 Attribute (vielleicht 60 Produktattribute). Wenn du dann noch mehr als einen Store in Magento hast, dann sind die Joins um die Daten eines einzigen Produkts abzufragen riesig. Und lade mal 20.000 Produkte per OOP in den Speicher. Da reichen dann 200 MB für einen PHP-Thread nicht mehr aus.

nikosch · 06.07.2011, 15:16

Zitat:

Und lade mal 20.000 Produkte per OOP in den Speicher.

WOzu wird das denn getan?

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Problem mit Mysql Left Join Ambfrage	pro-tech	Datenbanken	11	22.05.2010 10:59
[Erledigt] left join problem	Bernd-m	Datenbanken	9	24.08.2009 13:52
[Erledigt] MYSQL JOIN Problem	Sonatic	Datenbanken	4	28.05.2009 12:36
[Erledigt] Left Join Problem	scheffie	Datenbanken	7	04.05.2009 22:15
Persistence Framework	#Avedo	Software-Design	37	28.03.2009 17:32
Problem mit MySQL Select Statement	Hagbard-Celine	Datenbanken	5	25.03.2009 15:32
Problem mit INNER JOIN	#Avedo	Datenbanken	7	26.01.2009 10:42
[Erledigt] mit einer CHECKBOX feld nach mehreren wörtern durchsuchen	taurus	Datenbanken	20	01.12.2008 10:49
join array output Problem	Rilana	PHP Tipps 2008	3	17.11.2008 10:47
Select Problem		Datenbanken	17	16.01.2006 21:54
sql-Abfrage inner join - unerklärliches Problem	havok	Datenbanken	6	17.10.2005 14:32
Join Problem	Simon9990	PHP Tipps 2005-2	1	21.07.2005 22:15
[Erledigt] Problem mit JOIN		Datenbanken	7	27.08.2004 16:00

06.01.2011, 16:51
kaukat Neuer Benutzer Registriert seit: 23.12.2009 Beiträge: 6 PHP-Kenntnisse: Fortgeschritten	[Erledigt] EAV Model Join Problem Hallo zusammen, ich bin gerade dabei Teile einer existierenden DB in das EAV-Model umzuwandeln und ärgere mich schon seit Tagen mit den ewigst langen JOIN Abfragen rum. Meine Tabellenstruktur sieht aus wie die Grafik auf dieser Seite unter dem Punkt "Speicherung unterschiedlicher Datentypen" http://www.informave.org/de/database...esign_eav.html Weiters wären dort auch kleine Beispielauszüge aufgelistet, mit denen man in Kombination mit der Grafik jedoch leider nichts anfangen kann (zumindest ich nicht). Ich war jetzt mal so weit, dass ich diese Query absende (ich will 3 Werte - Produkt-ID, Preis und Bild): PHP-Code: select p.products_id, pprice.value products_price, pimage.value products_image from products_entity p inner join eav_attribute as eavattr on (p.entity_id = eavattr.entity_id) inner join attribute as attr on (eavattr.attribute_id = attr.attribute_id) left join product_value_decimal as pprice on (eavattr.eav_attribute_id = pprice.eav_attribute_id) left join product_value_varchar as pimage on (eavattr.eav_attribute_id = pimage.eav_attribute_id) where eavattr.entity_id = '102' and eavattr.attribute_id = attr.attribute_id and attr.attribute_name = 'price' or eavattr.entity_id = '102' and eavattr.attribute_id = attr.attribute_id and attr.attribute_name = 'image' durch den INNER JOIN von products_entity zu eav_attribute hab ich aber nun das Problem, dass ich für x Attribute auch x Ergebniszeilen bekomme, wobei in jeder Ergebniszeile alle Attribute bis auf eines NULL haben: products_id , products_price, products_image 102, NULL, 31U1Kc9aUHL._SL500_AA300_.jpg 102 ,88.7850, NULL ... ist mir durch diese Abfrage auch ganz klar warum und wieso, nur weiß jemand von euch einen einfacheren Weg die Attribute in einer Zeile gesammelt zu erhalten bzw. gibt es eine Möglichkeit alle Zeilen nach der ID so zu gruppieren, dass alle gewünschten Attribute in einer Zeile stehen wie z.B. products_id , products_price, products_image 102, 88.7850, 31U1Kc9aUHL._SL500_AA300_.jpg Falls euch die Grafik in Kombination mit meiner Query durch die unterschiedlichen Bezeichnungen verwirrt, bastel ich selbst noch schnell ein UML zusammen. zZ hab ichs bei einfacheren Abfragen mal ganz hässlich gelöst und alles im Nachhinein in Arrays abgespeichert mit IF-Abfragen ob der Wert nicht NULL ist, aber das kann es auch nicht sein, komplexere Abfragen sind damit nicht zu bewältigen.. ich hoffe ihr könnt mir hier weiterhelfen!


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

06.01.2011, 18:00
erc Erfahrener Benutzer Registriert seit: 02.01.2009 Beiträge: 730 PHP-Kenntnisse: Fortgeschritten	Erklär dich mal... was soll das werden wenns fertig ist? Ein Leitfaden alá "Wie verwende ich ein RDBMS falsch, richtig falsch" PS: Für das gewünschte Ergebniss brauchst du noch 2 Joins. Bei der Struktur brauchst du für jeden Wert den du auslesen willst 3 Joins wenn der Datentyp bekannt ist, 5 Joins wenn er nicht bekannt ist.

06.01.2011, 18:21
kaukat Neuer Benutzer Registriert seit: 23.12.2009 Beiträge: 6 PHP-Kenntnisse: Fortgeschritten	Jein, das EAV-Model hat genauso auch seine Vorteile in gewissen Bereichen wie z.B. bei E-Commerce Systemen. Magento z.B. setzt es schon seit längerem ein. Mein Fall hier bezieht sich auf ein Uni-Projekt in dem ich versch. DB-Modelle für E-Commerce Systeme untersuche, natürlich auch falsche Modelle inbegriffen Hm.. auf welche Tabellen beziehen sich die 2 weiteren Joins? Könntest du mir bitte ein Beispiel für die 3 bzw. 5 Joins geben?

06.01.2011, 22:21
kaukat Neuer Benutzer Registriert seit: 23.12.2009 Beiträge: 6 PHP-Kenntnisse: Fortgeschritten	Super, danke, klappt einwandfrei! Es war mir bei diesem Modell schon von Anfang an klar dass das ganze performancemäßig ziemlich in die Knie gehen wird, aber ansehen muss ichs mir im Rahmen meines Projekts trotzdem.. dass das auch Magento's Laster ist ist mir natürlich auch klar, Cache kommt bei mir in Schritt 2 auch noch dazu, in Schritt 3 geh ich dann weiter zu Key-Value Stores um dann evaluieren zu können was wie wo usw. um mein Paper schön füllen zu können, auch wenn ich letztendlich zu dem Ergebnis kommen könnte dass das alles wenig Sinn hat. Nochmals danke für deine Hilfe, alleine hätt ich dafür wohl noch eine ganze Weile gebraucht!

07.01.2011, 17:24
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Zugegeben ist Magento ziemlich langsam - Aber nicht aufgrund seiner Datenstruktur. Das Problem ist das Auslesen der Daten mittels einem riesigen OOP-Overhead. In unserem Unternehmen haben wir das in native SQL-Statements umgewandelt und es hat einen enormen Geschwindigkeitszuwachs gebracht. EAV an sich ist in meinen Augen ein super Prinzip.

06.07.2011, 10:35
SebboKleine Neuer Benutzer Registriert seit: 17.11.2010 Beiträge: 1 PHP-Kenntnisse: Fortgeschritten	Auch wenn der Thread schon etwas älter ist. Ich bin grad drüber gestolpert und möchte kurz was zu sagen. Magento hat zwei Probleme: EAV-Modell UND sein OOP-Overhead. Das erste haben sie in neueren Versionen durch "flat-tables" gelindert, das zweite versucht durch caching in den Griff zu bekommen. Richtig kritisch wird es erst bei höheren Produkt-Mengen. Bei 100 Produkte und 30 Attributen ist EAV toll. Und auch der OOP-Overhead nicht das Problem. Aber wehe du hast 150.000 Produkte und 400 Attribute (vielleicht 60 Produktattribute). Wenn du dann noch mehr als einen Store in Magento hast, dann sind die Joins um die Daten eines einzigen Produkts abzufragen riesig. Und lade mal 20.000 Produkte per OOP in den Speicher. Da reichen dann 200 MB für einen PHP-Thread nicht mehr aus.