Im letzten Beitrag schrieb ich über allgemeine Performance Mythen die auch heute noch durch schlecht konfigurierte webserver geglaubt werden. Der nächste Mythos über den ich reden möchte ist das EAV System.

Dazu muss ich zunächst aber einmal zugeben, dass Begriffe und Konzepte in Datenbanken nicht meine Stärke sind. Das liegt mit daran, dass hier wesentlich komplexereres passiert, als es für den einfachen Anwendungsprogrammierer ersichtlich ist. Ich werde womöglich sogar bei meiner vereinfachten Betrachtungsweise in einigen Punkten falsch liegen.

Nun aber zum wesentlichen. Immer wieder wird das EAV System, auf dem Magento für seine Produkte aufbaut, als größte Schwäche bezeichnet. Ich sehe das anders und behaupte dessen flexibilität ist mit der Grund, wieso Magento überhaupt erst so erfolgreich wurde. Das in Magento implementierte EAV System erfüllt dabei zwei Zwecke.

1. die Möglichkeit neue Attribute zu Produkten hinzufügen zu können.
2. den Produktattributen abhänig vom Storeview unterschiedliche Werte zu geben.

Der häufige Vorschlag diesen Teil mit einer Flat Table zu ersätzen ist dabei allerdings keine funktionierende Lösung. Die Funktionalität des zweiten Punktes damit umzusetzen würde dabei zu einer großen Menge an Null werten führen, die unnötig die Festplatte füllen. Und der erste Punkt wäre vor MySql 5.6 gar nicht gewährleistbar gewesen dadurch dass das ein Alter Table nötig ist.

• vorher wurde dabei eine neue Tabelle angelegt mit allen bisherigen und der einen neuen Spalte.
• Dann wurden alle Datensätze in die neue Tabelle kopiert
• Die alte wurde gelöscht und die neue Tabelle umbenannt, um den ursprünglichen Platz einzunehmen. Während des Vorganges gab es dadurch große Festplatten auslastung und dazu ein kompletten write Lock auf die Tabelle. Aktuelle MySql Versionen haben das zum Glück behoben und ein Alter Table ändert nur noch das Schema ohne alle Daten neu schreiben zu müssen. Das Problem mit einem unnötigen Aufblähen durch Null Werte bleibt aber bestehen.

Viele sehen hier auch Dinge als Lösung, die man gemeinhin unter dem Titel NoSql einordnet. Ich selbst zähle mich auch dazu. Der schreibende Teil davon sollte sogar recht einfach Umsetzbar sein. Probleme sehe ich bei den Collections im Zusammenspiel mit Filtern, da diese ja abhänig vom Storeview unterschiedliche Werte inklusive ihren Fallbacks beachten müssen. Die Komplexität dahinter betrachtend wird es eventuell sogar sinnvoller sein direkt auf Suchserver wie Solr oder elasticSearch zu setzen. Zumindest für den allgemeinen Fall (in dem allgemein keines von beidem Anwendung findet).