EAV-Modell (Entity-Attribute-Value)

Das EAV-Modell (Entity-Attribute-Value, deutsch: Entität-Attribut-Wert) ist ein Datenbank-Entwurfsmuster, bei dem die Eigenschaften eines Objekts nicht als feste Spalten einer Tabelle gespeichert werden, sondern als einzelne Datensätze aus drei Bausteinen: der Entität (dem Objekt), dem Attribut (der Eigenschaft) und dem Wert. Im E-Commerce ist EAV vor allem als das Produktdatenmodell von Magento bekannt — und genau dort wird es bei einer Migration auf ein anderes Shopsystem zur zentralen Herausforderung.

Wie das EAV-Modell funktioniert

In einer klassischen relationalen Tabelle hat ein Produkt feste Spalten: eine Spalte für den Namen, eine für den Preis, eine für das Gewicht. Jede neue Eigenschaft bedeutet eine neue Spalte. Das ist schnell und übersichtlich, aber unflexibel: Wer für eine einzelne Warengruppe zwanzig Spezialattribute braucht, bläht die Tabelle für alle anderen Produkte mit auf.

Das EAV-Modell dreht dieses Prinzip um. Statt breiter Tabellen mit vielen Spalten gibt es schmale Tabellen mit wenigen Spalten und vielen Zeilen. Vereinfacht sieht eine Wertzeile so aus: „Entität 1234 (das Produkt) hat für Attribut 'Farbe' den Wert 'blau'". Jede Eigenschaft eines Objekts wird zu einer eigenen Zeile. Drei Bausteine bilden das Modell:

• Entität (Entity): das Objekt selbst, etwa ein konkretes Produkt mit einer eindeutigen ID.
• Attribut (Attribute): die Art der Eigenschaft, etwa „Farbe", „Material" oder „Gewicht". Attribute werden zentral definiert und sind beliebig erweiterbar.
• Wert (Value): der konkrete Inhalt der Eigenschaft für diese eine Entität, etwa „blau" oder „250 g".

Der entscheidende Kniff: Weil Werte unterschiedliche Datentypen haben (Text, Zahl, Datum), werden sie in der Praxis nicht in einer einzigen Wert-Tabelle gespeichert, sondern nach Typ getrennt. Genau das führt zur charakteristischen Zersplitterung, die EAV-Datenbanken so aufwändig auszulesen macht.

Ein Beispiel: ein Produkt über viele Tabellen

Stell dir ein T-Shirt mit Name, Preis, Farbe, Größe und einem Veröffentlichungsdatum vor. In einem flachen Modell wäre das eine Zeile mit fünf Spalten. Im EAV-Modell von Magento verteilt sich dasselbe Produkt über mehrere Tabellen: Der Name (Text) landet in catalog_product_entity_varchar, der Preis (Zahl) in catalog_product_entity_decimal, das Datum in catalog_product_entity_datetime, ganzzahlige Werte in catalog_product_entity_int und lange Beschreibungstexte in catalog_product_entity_text. Um das vollständige Produkt zu rekonstruieren, muss die Datenbank diese Tabellen über die Entitäts-ID wieder zusammenführen (joinen). Ein einziges Produkt zu laden, kann so ein Dutzend Tabellenzugriffe bedeuten.

EAV bei Magento und Adobe Commerce

Magento (und die kommerzielle Variante Adobe Commerce) nutzt EAV für seine Kern-Entitäten: Produkte, Kategorien, Kunden und Bestelladressen. Der historische Grund ist Flexibilität. Ein Händler kann im Backend beliebig viele eigene Attribute (in Magento „custom attributes") anlegen, ohne dass ein Entwickler das Datenbankschema ändern muss. Für sehr große, heterogene Kataloge mit stark unterschiedlichen Produkttypen ist das ein echter Vorteil — ein Möbelhändler und ein Elektronikhändler können dieselbe Magento-Installation mit völlig verschiedenen Attributsätzen betreiben.

Der Preis für diese Flexibilität ist Komplexität und Performance. Weil jede Abfrage über mehrere Tabellen joinen muss, ist EAV lese-intensiv. Magento gleicht das mit aggressivem Caching, Flat-Tables (zusammengefassten, denormalisierten Lese-Tabellen) und Indexern aus. Diese Mechanik funktioniert, macht den Datenbestand aber undurchsichtig — und genau diese Undurchsichtigkeit schlägt bei einer Migration zu.

Vor- und Nachteile auf einen Blick

EAV gegenüber dem Entitätsmodell von Shopware 6

Shopware 6 geht einen anderen Weg. Statt EAV nutzt es eine klar geschnittene Datenstruktur, die über die hauseigene Data Abstraction Layer (DAL) angesprochen wird. Produkte, Eigenschaften (Properties) und Varianten haben definierte Entitäten und Felder. Eigene Zusatzfelder werden über sogenannte Custom Fields abgebildet, nicht über ein vollständiges EAV-Schema. Das Ergebnis ist ein Datenmodell, das leichter zu lesen, zu validieren und programmatisch zu befüllen ist — auf Kosten der grenzenlosen Attributflexibilität, die Magento bietet.

Für die meisten Händler im Mittelstand ist dieser Tausch ein Gewinn: weniger Komplexität, vorhersehbarere Performance, einfacher zu wartende Schnittstellen. Für sehr große, attributgetriebene Enterprise-Kataloge kann die Flexibilität von EAV dagegen weiterhin ihren Wert haben.

Warum EAV bei einer Migration zur Herausforderung wird

Wer von Magento auf Shopware 6 wechselt, überträgt Daten aus einem EAV-Modell in ein Entitätsmodell. Zwischen beiden gibt es keine eins-zu-eins-Übersetzung. Besonders heikel sind konfigurierbare Produkte und Varianten: In Magento hängen Varianten als eigene „configurable product"-Konstruktion an einem Elternprodukt, in Shopware entstehen sie aus Properties und einer Variantenmatrix. Wer die EAV-Struktur unbesehen überträgt, riskiert doppelte Produkte, fehlende Kombinationen oder Varianten, die im Shop nicht mehr auswählbar sind.

Deshalb genügt ein Standard-Importer selten. In vielen Projekten braucht es ein Mapping-Skript oder ein Middleware-Werkzeug, das die verstreuten EAV-Werte einliest, dem richtigen Shopware-Feld zuordnet und Varianten korrekt aufbaut. Je individueller das Magento-Datenmodell ist — viele eigene Attribute, komplexe Varianten-Achsen, gewachsene Kategoriestrukturen — desto mehr wird aus der Migration ein echtes Datenprojekt. Das EAV-Modell zu verstehen, ist damit die Voraussetzung dafür, den Aufwand einer Shopware-Migration realistisch zu kalkulieren.

EAV und Performance: Indexer, Flat Tables und Caching

Die größte praktische Schwäche von EAV ist die Lese-Performance. Weil ein Produkt über viele Tabellen verteilt liegt, würde jede Storefront-Abfrage ohne Gegenmaßnahmen eine Flut von Joins auslösen. Magento begegnet dem mit mehreren Schichten. Indexer berechnen aufwändige Daten (Preise, Lagerbestände, Kategorie-Zuordnungen) im Voraus und legen sie in optimierten Index-Tabellen ab. Flat Tables fassen die verstreuten EAV-Werte eines Produkts oder einer Kategorie in einer einzigen, denormalisierten Lese-Tabelle zusammen, sodass die Storefront nicht den vollen EAV-Aufbau durchlaufen muss. Darüber liegt aggressives Caching, oft über Varnish und Redis.

Diese Maschinerie funktioniert, hat aber einen Preis: Sie muss konfiguriert, überwacht und nach Datenänderungen neu aufgebaut werden. Ein Reindex über einen großen Katalog kann spürbar Zeit kosten, und falsch eingestellte Indexer sind eine häufige Ursache für lahme Magento-Shops. Wer von Magento wegmigriert, lässt damit auch diese Betriebskomplexität hinter sich — Shopware 6 kommt ohne das EAV-bedingte Indexer-Geflecht aus.

Woher das EAV-Modell stammt

EAV ist keine Erfindung des E-Commerce. Das Muster ist in der Informatik seit Jahrzehnten bekannt und überall dort verbreitet, wo Objekte sehr viele, sehr unterschiedliche und nicht im Voraus festgelegte Eigenschaften haben. Ein klassisches Beispiel sind klinische Datensysteme: In der Medizin existieren zehntausende mögliche Befunde und Messwerte, von denen ein einzelner Patient nur eine kleine Auswahl trägt. Ein flaches Tabellenschema mit einer Spalte pro denkbarem Befund wäre nicht handhabbar. EAV löst genau dieses Problem, indem nur die tatsächlich vorhandenen Eigenschaften als Zeilen gespeichert werden. Das gleiche Argument gilt für Produktkataloge mit hunderten Produkttypen, weshalb Magento sich früh für EAV entschieden hat.

Dieses „sparse data"-Problem — viele mögliche, aber je Objekt nur wenige belegte Attribute — ist der eigentliche Daseinsgrund von EAV. Wer es kennt, versteht auch, warum EAV dort, wo Produkte einheitlich strukturiert sind, mehr Last als Nutzen bringt.

EAV, JSON-Spalten und andere Alternativen

EAV ist nicht der einzige Weg, flexible Attribute abzubilden. Moderne Datenbanken bieten Alternativen, die je nach Anwendungsfall einfacher sind:

• JSON-Spalten: Variable Attribute werden als JSON-Dokument in einer einzigen Spalte gespeichert. Das spart Joins, erschwert aber gezielte, indizierte Abfragen über einzelne Attribute.
• Flache Tabellen mit vielen Spalten: Schnell und einfach, aber unflexibel und bei hunderten optionalen Spalten unübersichtlich.
• Hybridmodelle: Häufig genutzte Attribute als feste Spalten, seltene als JSON oder Zusatzfeld. Shopware 6 geht mit seinem Entitätsmodell plus Custom Fields in diese Richtung.

Die Wahl ist immer ein Kompromiss zwischen Flexibilität, Abfrage-Performance und Wartbarkeit. EAV maximiert die Flexibilität und zahlt dafür mit Komplexität — ein Tausch, der für Magentos Anspruch sinnvoll war, für viele Mittelstandsshops aber überdimensioniert ist.

EAV in der Praxis lesen und exportieren

Wer Magento-Daten exportiert, merkt schnell, dass ein simpler Tabellen-Dump nicht reicht. Um ein vollständiges Produkt zu erhalten, müssen die Wert-Tabellen je Datentyp über die Entitäts-ID und die Attribut-ID zusammengeführt werden. Zusätzlich spielt der „Store-Scope" eine Rolle: Magento speichert Attributwerte pro Store-View, sodass derselbe Attributwert in mehreren Sprachvarianten existieren kann. Ein Export muss entscheiden, welche Scope-Ebene gilt. Genau diese Feinheiten — Datentyp-Trennung, Attribut-Sets, Store-Scopes, Standardwerte — machen das Auslesen eines EAV-Bestands zur Spezialaufgabe und sind der Grund, warum generische Export-Tools bei Magento oft unvollständige Ergebnisse liefern.

Häufige Fragen zum EAV-Modell

Wofür steht EAV? EAV steht für Entity-Attribute-Value, also Entität, Attribut und Wert — die drei Bausteine, aus denen das Datenmodell die Eigenschaften eines Objekts zusammensetzt.

Warum nutzt Magento EAV? Um Produkte, Kategorien und Kunden mit beliebig vielen eigenen Attributen erweiterbar zu machen, ohne bei jeder neuen Eigenschaft das Datenbankschema ändern zu müssen.

Ist EAV langsam? EAV ist lese-intensiv, weil Daten über viele Tabellen verteilt liegen und per Join zusammengeführt werden müssen. Magento gleicht das mit Flat-Tables, Indexern und Caching aus.

Nutzt Shopware 6 auch EAV? Nein. Shopware 6 verwendet ein klar geschnittenes Entitätsmodell über die Data Abstraction Layer (DAL) und bildet Zusatzfelder über Custom Fields ab, nicht über ein vollständiges EAV-Schema.

Warum ist EAV bei einer Migration relevant? Weil die verstreute EAV-Struktur von Magento nicht eins zu eins in das Shopware-Modell passt — besonders bei Varianten — und deshalb ein durchdachtes Daten-Mapping braucht.

Lassen sich EAV-Daten einfach als CSV exportieren? Nur eingeschränkt. Ein vollständiger Export muss die nach Datentyp getrennten Wert-Tabellen über die Entitäts- und Attribut-IDs zusammenführen und die Store-Scopes berücksichtigen. Generische CSV-Exporte liefern deshalb oft unvollständige oder falsch zugeordnete Daten.

Ist EAV grundsätzlich schlecht? Nein. Für Domänen mit sehr vielen optionalen Attributen ist EAV ein sinnvolles Muster. Es ist nur dort überdimensioniert, wo Objekte einheitlich strukturiert sind — wie in vielen Mittelstandskatalogen.

Weiterführend: eine ausführliche, sprachneutrale Beschreibung des Musters findet sich im Wikipedia-Artikel zum Entity–attribute–value model.