Wie groß das Datenmodell von Shopware wirklich ist
231 Kernentitäten in 6.7, 217 in 6.6. Übersetzbar sind 49 davon, Custom Fields erlauben 85. Die Zahlen sagen mehr über Migrationsaufwand als jede Feature-Liste.
Ergebnis
231 Kernentitäten in 6.7 gegen 217 in 6.6
Übersetzbar sind 49 davon (6.6: 44), Custom Fields erlauben 85 (6.6: 83). Die Rohsummen inklusive der installierten Erweiterungen liegen bei 247 und 228. Der Zuwachs von 14 Kernentitäten ist kein gleichmäßiges Wachstum: Ein neues Maßsystem bringt allein zwei Übersetzungstabellen mit.
„Shopware ist groß" ist keine Aussage, mit der sich planen lässt. Für eine Migration, eine Schnittstelle oder eine Mehrsprachigkeitsentscheidung braucht man Zahlen. Wir haben sie an zwei laufenden Installationen erhoben — nicht aus der Dokumentation, sondern aus dem Kernel selbst.
Die Zählung
Ausgelesen haben wir die DefinitionInstanceRegistry beider Kernel. Dort ist
jede Entität registriert, die der laufende Shop kennt. Jede Definition haben
wir nach dem Namensraum ihrer Klasse eingeordnet: Kern oder Erweiterung.
| 6.6.10.6 | 6.7.13.1 | Differenz | |
|---|---|---|---|
| Kernentitäten | 217 | 231 | +14 |
| Rohsumme mit Erweiterungen | 228 | 247 | +19 |
| davon übersetzbar | 44 | 49 | +5 |
| mit Custom-Fields-Feld | 83 | 85 | +2 |
Die Trennung nach Herkunft ist notwendig, weil beide Testsysteme unterschiedliche Erweiterungen tragen. Ohne sie vergleicht man zwei Installationen, nicht zwei Versionen.
Was die drei Zahlen jeweils bedeuten
231 Kernentitäten: die Breite des Modells
Das ist die Fläche, die eine Migration abbilden muss — theoretisch. Praktisch berührt ein typischer Shop einen Bruchteil davon: Produkte, Kategorien, Kunden, Bestellungen, Medien, Regeln, Inhalte. Der Rest ist Infrastruktur, Versionierung, App-System, Protokolle.
Die Zahl ist trotzdem nützlich, wenn jemand eine vollständige Abbildung in ein anderes System verspricht. 231 Entitäten bedeuten: Es gibt keine vollständige Abbildung, es gibt eine Auswahl. Die Frage ist nur, wer sie trifft.
49 übersetzbare Entitäten: der Multiplikator
Das ist die wichtigste der drei Zahlen, sobald ein Shop mehrsprachig wird. Jede übersetzbare Entität führt eine eigene Übersetzungstabelle, und in der steht je Sprache ein eigener Datensatz.
Ein Shop mit fünf Sprachen hat nicht fünfmal so viel Inhalt, aber in diesen 49 Bereichen fünfmal so viele Zeilen — und jede davon kann gepflegt, veraltet oder leer sein. Was daraus folgt, haben wir getrennt untersucht: welche Produktdaten überhaupt sprachabhängig sind und wie man sie ohne Datenverlust übersetzt.
Die fünf neuen übersetzbaren Entitäten in 6.7 sind kein Zufall: Zwei davon
gehören zum neuen Maßsystem (measurement_display_unit_translation und
measurement_system_translation). Wer Maßeinheiten mehrsprachig ausgibt,
bekommt hier einen Bereich dazu, den es vorher nicht gab.
85 Entitäten mit Custom Fields: die erlaubte Erweiterungsfläche
Custom Fields sind die einfachste Art, eigene Daten unterzubringen — und die mit den meisten Folgekosten, wenn man sie an der falschen Stelle einsetzt. Dass 85 Entitäten sie erlauben, ist eine technische Obergrenze, keine Empfehlung.
Wann ein Custom Field genügt und wann eine eigene Entität die bessere Wahl ist, haben wir an der Frage Custom Field oder eigene Entität durchgespielt. Die Kurzfassung: Sobald mehrere Werte, eigene Beziehungen oder eine eigene Lebensdauer im Spiel sind, ist das Custom Field die teurere Lösung.
Was der Zuwachs von 14 Entitäten aussagt
Ein Versionssprung, der 14 Kernentitäten hinzufügt, ändert das Datenmodell spürbar — aber nicht gleichmäßig. Der Zuwachs konzentriert sich auf wenige Themen. Das neue Maßsystem ist das sichtbarste Beispiel: Es bringt eigene Entitäten samt Übersetzungen mit.
Für die Planung eines Umstiegs ist das die angenehmere Sorte Veränderung: neue Bereiche neben den alten, nicht umgebaute alte. Was sich an der Datenbank tatsächlich ändert — Tabellen, Spalten, Schlüssel —, haben wir in Was ein Versionssprung an der Datenbank tut vermessen. Beide Messungen gehören zusammen: Die eine zählt Definitionen, die andere Strukturen.
Warum wir nicht Tabellen gezählt haben
Naheliegend wäre gewesen, SHOW TABLES auszuführen. Das hätte eine andere
Zahl ergeben und eine unschärfere. Eine Entität kann mehrere Tabellen
berühren, Zuordnungstabellen haben eigene Definitionen, und Views tauchen
auf, die fachlich nichts Eigenes sind.
Die Registry ist die Sicht des Systems auf sich selbst: Was dort steht, kennt der Kern als eigenständige Sache — mit Feldern, Beziehungen und Regeln. Für die Frage „wie groß ist das Modell" ist das die ehrlichere Zählung.
Einordnung für die Praxis
- Migration geplant? Die 231 sind die Obergrenze, nicht der Aufwand. Erstellen Sie die Liste der tatsächlich genutzten Entitäten, bevor Sie schätzen lassen.
- Mehrsprachigkeit geplant? Die 49 sind der Multiplikator. Sie entscheiden über Pflegeaufwand und Übersetzungskosten mehr als die Zahl der Produkte.
- Eigene Felder geplant? Die 85 sagen, wo es geht. Ob es soll, ist eine Architekturfrage.
- Versionswechsel geplant? Der Zuwachs ist additiv. Das senkt das Risiko, ersetzt aber keinen Test der eigenen Erweiterungen.
Häufige Fragen
- Wie viele Entitäten hat Shopware 6.7?
- In unserer Messung 231 im Kern, 247 inklusive der installierten Erweiterungen der Testinstallation. In 6.6.10.6 waren es 217 beziehungsweise 228.
- Wie viele Shopware-Entitäten sind übersetzbar?
- 49 in 6.7.13.1 und 44 in 6.6.10.6. Übersetzbar heißt: Die Definition führt ein TranslationsAssociationField, es gibt also eigene Datensätze je Sprache.
- Wo kann ich in Shopware eigene Felder anlegen?
- An 85 Entitäten in 6.7 und 83 in 6.6 — überall dort, wo die Definition ein customFields-Feld führt. Das ist die technische Obergrenze, nicht eine Empfehlung.
- Was bedeutet die Größe des Datenmodells für eine Migration?
- Sie bestimmt den Umfang der Abbildung. Nicht jede Entität ist für jeden Shop relevant, aber jede übersetzbare Entität vervielfacht die Datensätze mit der Zahl der Sprachen.