Block 1 hat mit dem Punkte-Ledger bewusst eine schlichte, flache Tabelle gebaut: eine Spalte pro Eigenschaft, ein ResourceModel, das direkt auf AbstractDb aufsetzt. Block 2 baut die zweite Kern-Entität dieser Serie - die Prämie ("Reward") - komplett anders: als EAV-Entity, nach demselben Muster wie catalog_product_entity. Bevor Kapitel 11 die Tabellen entwirft, muss klar sein, was EAV überhaupt ist und warum Magento es gerade für Produkte, Kategorien und Kunden einsetzt - und, ebenso wichtig, wann es sich nicht lohnt.

Was ist EAV?

EAV steht für Entity-Attribute-Value. Statt wie bei einer klassischen relationalen Tabelle eine feste Spalte pro Eigenschaft anzulegen (title, points_cost, reward_type als Spalten in einer einzigen Tabelle - genau das Muster aus dem Punkte-Ledger), speichert EAV jede einzelne Eigenschaft als eigene Zeile in einer separaten Tabelle: eine Zeile pro Kombination aus Entität, Attribut und Wert.

• Entity - die Hauptzeile in der Haupttabelle, hier mironsoft_loyalty_reward_entity, mit einer festen, kleinen Zahl an Kernspalten (entity_id, attribute_set_id, identifier und so weiter).
• Attribute - eine Eigenschaft wie title oder points_cost, als Datensatz in der zentralen, von Magento_Eav bereitgestellten Tabelle eav_attribute definiert, nicht als Tabellenspalte.
• Value - der eigentliche Wert einer Entität für ein Attribut, gespeichert in einer von fünf Wertetabellen, aufgeteilt nach PHP-Skalartyp (_varchar, _int, _decimal, _text, _datetime).

Um den Titel und den Punktepreis einer einzelnen Prämie zu lesen, braucht es also nicht eine Zeile aus einer Tabelle, sondern die Hauptzeile plus je eine Zeile aus mironsoft_loyalty_reward_entity_varchar (für title) und mironsoft_loyalty_reward_entity_int (für points_cost) - verbunden über entity_id.

Warum nutzt Magento EAV für Produkte und Kunden?

Der Grund ist nicht akademisch, sondern praktisch: catalog_product, catalog_category und customer haben eine stark variierende Anzahl an Attributen - ein T-Shirt hat eine Größe und Farbe, ein Buch einen Autor und eine ISBN, ein B2B-Kunde eine Firmen-Zuordnung, ein Privatkunde nicht. Neue Attribute müssen sich außerdem ohne Code-Deployment hinzufügen lassen - ein Shop-Betreiber legt im Admin ein neues Produktattribut an, ohne dass jemand ALTER TABLE ausführen oder ein Modul deployen muss. Genau das ist die Stärke von EAV: neue Attribute sind reine Daten (eine Zeile in eav_attribute), keine Schemaänderung.

Passt EAV wirklich zu einer Prämie?

Ehrliche Antwort: nicht zwingend. Die Prämie in dieser Serie hat genau sechs fest definierte Attribute (title, description, points_cost, discount_value, reward_type, is_active) - keine Attribut-Sets mit stark unterschiedlichen Eigenschaften wie beim Produktkatalog, keine im laufenden Betrieb vom Shop-Betreiber frei hinzufügbaren Felder. Eine schlichte, flache Tabelle nach dem Muster des Punkte-Ledgers aus Block 1 wäre technisch genauso tragfähig - mit dem Vorteil spürbar einfacherer und schnellerer Abfragen.

Zwei Gründe rechtfertigen die EAV-Entscheidung trotzdem, und beide sind real, nicht nur didaktisch: Erstens ist ein Prämienkatalog genau die Art Entität, die in einem wachsenden Shop typischerweise zusätzliche, merchant-spezifische Attribute ansammelt - eine Saison-Kennzeichnung, eine Mindest-Treue-Stufe, ein Bezug auf ein bestimmtes Produkt, ein zusätzliches Bild - ohne dass jede dieser Erweiterungen ein neues Modul-Release rechtfertigt. Zweitens ist "eine eigene EAV-Entity bauen" einer der 32 angeforderten Modul-Bereiche dieser Serie (siehe Kapitel 1) - ein Thema, das ohne ein konkretes, durcharbeitbares Beispiel nur abstrakt bliebe.

Die Tabellenstruktur auf einen Blick

mironsoft_loyalty_reward_entity            (Haupttabelle, eine Zeile pro Prämie)
mironsoft_loyalty_reward_entity_varchar     (title, reward_type)
mironsoft_loyalty_reward_entity_int         (points_cost, is_active)
mironsoft_loyalty_reward_entity_decimal     (discount_value)
mironsoft_loyalty_reward_entity_text        (description)
mironsoft_loyalty_reward_entity_datetime    (aktuell ungenutzt, Reserve für spätere Datums-Attribute)

Das EAV-Vokabular für den Rest des Blocks

• Entity Type - der eindeutige Code einer EAV-Entität in eav_entity_type, hier mironsoft_loyalty_reward (Kapitel 13).
• Attribute - eine einzelne Eigenschaft, definiert in eav_attribute, mit einem backend_type (welche Wertetabelle) und einem frontend_input (welches Admin-Formularfeld) - Kapitel 13 und 14.
• Attribute Set und Attribute Group - eine benannte Gruppierung von Attributen ("Default"-Set, "General"-Gruppe reichen für Rewards völlig aus) - Kapitel 13.
• backend_type - der PHP-Skalartyp eines Attributs (varchar, int, decimal, text, datetime), bestimmt, in welcher der fünf Wertetabellen der Wert landet - Kapitel 14.

Die nächsten drei Kapitel bauen das Fundament von unten nach oben auf: Kapitel 11 legt die Tabellen selbst per db_schema.xml an, Kapitel 12 schreibt Model und ResourceModel dafür, und Kapitel 13 registriert den Entity Type und die sechs Attribute per Setup-Skript - erst danach existiert eine tatsächlich nutzbare Prämien-Entität.