Was ist eigentlich EAV?

WAS IST EIGENTLICH EAV?
Eine Einführung in das Entity-Attribute-Value Model

PHP User Group Rheinhessen
12.01.2010 Mainz

Daniel Nitz — www.danielnitz.de 1 12.01.2010 — PHPUG-RHH

AGENDA

1. Deﬁnition 4. Nachteile

2. Anwendungsbeispiel 5. In der Praxis

3. Vorteile 6. Fazit


DEFINITION


DEFINITION

Entity-Attribute-Value Model, auch bekannt als Object-
Attribute-Value Model und Open Schema ist ein Datenmodell,
welches dann zum Einsatz kommt, wenn die Anzahl der
Attribute (Eigenschaften, Parameter) zur Beschreibung einer
Sache (Entität oder Objekt) im Vorfeld nicht vorhersehbar sind.


DEFINITION

EAV ist ein Datenmodell für den Fall, dass die Anzahl der
Attribute eines Objektes nicht vorhersehbar sind.


DEFINITION

Entity: Repräsentiert einen Datensatz, z.B. eine Produkt.

Attribute: Stellt eine Eigenschaft dar, z.B. Größe, Farbe etc.

Value: Beinhaltet den Eigenschaftswert, z.B. XL, blau etc.


DEFINITION

1:n 1:1
Entity Attribute Value

3 Tabellen verknüpft mittels Foreign Keys.


HÄ?


ANWENDUNGSBEISPIEL
Unterschied EAV im Vergleich zum relationalen Design


ANWENDUNGSBEISPIEL

‣ Eine Person wird anhand einer eindeutigen Nummer
identiﬁziert

‣ Eine Person hat einen Vornamen

‣ Eine Person hat einen Nachnamen

‣ Ein Person hat eine beliebige Anzahl von zusätzlichen
Informationen (Alter, Gewicht, Größe etc.)

RELATIONALES DESIGN
Person Data

person_id 1:1 person_id
ﬁrst_name age
last_name weight
height


EAV DESIGN

1:1
entity_id 1:n
attribute_id attribute_id
entity_id value
attribute_name


STORY
Relationales Design:
Die Person mit der Nummer 1 hat das Alter 30, hat ein Gewicht von 80,
hat eine Größe von 180.

EAV Design:
Die Person mit der Nummer 1 hat das Attribut Alter mit dem Wert 30.

Die Person mit der Nummer 1 hat das Attribut Gewicht mit dem Wert 80.

Die Person mit der Nummer 1 hat das Attribut Größe mit dem Wert 180.


DESIGN PROBLEME

‣ keine Datentypen

‣ keine deﬁnierten Spalten-/Attributsets

‣ Redundanz von Attributen

‣ keine Integrität


EAV DESIGN

1:1
entity_id 1:n
attribute_id attribute_id
entity_id value_id
attribute_name

1:1 1:1

Value Int Value ...

value_id value_id
value value


EAV DESIGN

Entity Entity_Attribute Value
1:1
entity_id 1:n
ea_id ea_id
entity_id value_id
attribute_id
as_id
1:1 1:1

Attribute Set Attribute Value Int Value ...

as_id attribute_id value_id value_id
as_name attribute_name value value


DESIGN PROBLEME

‣ verschiedene Datentypen

‣ deﬁnierte Spalten-/Attributsets

‣ keine Redundanz von Attributen

‣ Integrität gewahrt


VORTEILE


VORTEILE

‣ Hohe Flexibilität in der Gestaltung von Objektstrukturen

‣ Kein DBA zur Änderung der Schemata nötig

‣ Keine zusätzliche Programmierung bei Änderung der
Schemata nötig


NACHTEILE


NACHTEILE

‣ Hohe Systemlast durch komplizierte SQL Queries

‣ Komplexe Programmierung von SQL Statements

‣ Verlust von DBMS-speziﬁschen Funktionalitäten

‣ Verlagerung von DBMS-Funktionen in die Anwendungslogik


IN DER PRAXIS


EAV MODEL LIBRARY

Dmg_Db_Eav:
‣ EAV Model Implementierung für das Zend Framework

‣ Auf Basis von Zend_Db und Zend_Db_Table

‣ Nutzung von Zend_Cache


CODE BEISPIEL

$options = new Dmg_Db_Eav_Config($array);

// Person implements Dmg_Db_Eav_Abstract
$personModel = new Person($options);

$persons = $personModel->addAttributeFilter('age', 30)
->addAttributeFilter('name', 'daniel')
->addFilter('active', 1)
->addLimit(10)
->load();


CODE BEISPIEL
foreach ($persons as $person) {
$attributes = $person->getAttributes();
foreach ($attributes as $attribute) {
if (!$attribute->hasOptions()) {
echo $attribute->getName() . ': ' . $attribute->getValue();
} else {
foreach ($attribute->getOptions() as $option) {
echo $option->getName() . ': ' . $option->getValue();
}
}
}
}


PERFORMANCE
# Time Query
1 0.223762989044 connect

SELECT è`.*, `v`.*, à`.*, às`.*, `g`.*, `ga`.* FROM èav_entity` AS è` INNER JOIN èav_value` AS `v` ON e.entity_id = v.entity_id INNER
JOIN èav_attribute` AS à` ON v.attribute_id = a.attribute_id INNER JOIN èav_attribute_set` AS às` ON e.attribute_set_id =
2 0.42297410965
as.attribute_set_id INNER JOIN èav_attribute_group` AS `g` ON g.attribute_set_id = as.attribute_set_id INNER JOIN
èav_attribute_group_attribute` AS `ga` ON a.attribute_id = ga.attribute_id WHERE (e.entity_id = 1)

3 0.0507569313049 DESCRIBE èav_entity`

SELECT eav_value_varchar.*, CONCAT('varchar') AS type FROM eav_value_varchar WHERE value_id IN (1, 3) UNION SELECT
4 0.757645130157 eav_value_int.*, CONCAT('int') AS type FROM eav_value_int WHERE value_id IN (2) UNION SELECT eav_value_text.*, CONCAT('text') AS
type FROM eav_value_text WHERE value_id IN (4)

... ... ...

Query Zeit beim Laden eines EAV Objektes ohne Cache mit 4
Attributen, eines davon hat 6 Attributoptionen: 1.949 sec
Nach dem Caching: 0.079 sec

FAZIT


FAZIT

‣ EAV bietet gute Möglichkeiten eine Anwendung in der
Datenschicht ﬂexibel zu halten.

‣ Es gibt jedoch nur wenige Anwendungsfälle, in denen eine EAV
Implementierung wirklich sinnvoll ist.

‣ Ein relationales Design sollte dem EAV, wenn möglich,
vorgezogen werden.


VIELEN DANK!

Daniel Nitz
[ zend certiﬁed engineer ]

daniel@danielnitz.de
twitter.com/danielnitz


Was ist eigentlich EAV?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Was ist eigentlich EAV?