Magento Datenbank verstehen: Die wichtigsten Core-Tabellen im Überblick

Die Magento Datenbank: Mehr als nur Produktdaten

Wer die Magento Datenbank zum ersten Mal öffnet, ist überrascht: Über 400 Tabellen, davon viele mit kryptischen Namen wie eav_attribute_option_value oder catalogrule_product_price. Dabei gibt es eine Handvoll Core-Tabellen, die das gesamte System zusammenhalten und die jeder Magento-Entwickler und -Administrator kennen sollte.

Dieser Artikel führt durch die wichtigsten Kategorien: das Konfigurationssystem (core_config_data), die Store-Hierarchie, das EAV-Attributsystem, CMS-Inhalte, URL-Verwaltung und das Berechtigungssystem. Zu jeder Tabelle gibt es konkrete SQL-Abfragen, die im Entwicklungsalltag sofort nützlich sind.

1. Konfiguration: core_config_data

Die Tabelle core_config_data ist das Rückgrat des Magento-Konfigurationssystems. Sie speichert alle Einstellungen aus dem Admin-Panel (System → Konfiguration) als einfache Schlüssel-Wert-Paare. Das Scope-System erlaubt unterschiedliche Werte auf drei Ebenen: global, Website und Store View.

-- Alle Einstellungen für einen bestimmten Pfad über alle Scopes
-- scope-Werte: 'default' (scope_id=0), 'websites' (=website_id), 'stores' (=store_id)
SELECT
    config_id,
    scope,
    scope_id,
    path,
    value,
    updated_at
FROM core_config_data
WHERE path LIKE 'catalog/frontend/%'
ORDER BY scope, scope_id;

-- Den effektiven Wert einer Konfiguration für Store 2 ermitteln
-- Magento-Priorität: stores > websites > default
SELECT path, scope, scope_id, value
FROM core_config_data
WHERE path = 'general/locale/timezone'
  AND (
      (scope = 'stores'   AND scope_id = 2) OR
      (scope = 'websites' AND scope_id = (SELECT website_id FROM store WHERE store_id = 2)) OR
      (scope = 'default'  AND scope_id = 0)
  )
ORDER BY FIELD(scope, 'stores', 'websites', 'default')
LIMIT 1;

2. Store-Hierarchie: store, store_website, store_group

Magento kennt drei Hierarchieebenen. Das Verständnis dieser Ebenen ist entscheidend für das Scope-System in core_config_data und für Multi-Store-Setups. Jede Ebene hat eine eigene Tabelle und eigene Konfigurationsmöglichkeiten.

-- Komplette Store-Hierarchie in einer Abfrage
SELECT
    sw.website_id,
    sw.code         AS website_code,
    sw.name         AS website_name,
    sg.group_id,
    sg.name         AS store_group_name,
    sg.root_category_id,
    s.store_id,
    s.code          AS store_code,
    s.name          AS store_view_name,
    s.is_active,
    s.sort_order
FROM store_website sw
JOIN store_group sg ON sg.website_id = sw.website_id
JOIN store s ON s.group_id = sg.group_id
WHERE sw.website_id > 0   -- Admin-Website ausschließen
ORDER BY sw.website_id, sg.group_id, s.sort_order;

Jede Website hat einen Standard-Store-Group, und jede Store-Group hat einen Standard-Store-View. Diese Defaults sind über default_group_id bzw. default_store_id gesetzt. Wenn eine Konfiguration auf Store-Ebene nicht vorhanden ist, fällt Magento auf die Website-Ebene und dann auf Default zurück.

3. EAV-System: eav_entity_type, eav_attribute

Das EAV-Muster (Entity-Attribute-Value) ist das charakteristische Merkmal der Magento-Datenbank. Es ermöglicht, Produkten, Kunden und Kategorien beliebige Attribute hinzuzufügen, ohne das Datenbankschema zu ändern. Der Preis ist Komplexität: Attribute werden auf mehrere Tabellen verteilt.

-- Alle registrierten Entity-Typen in Magento
SELECT
    entity_type_id,
    entity_type_code,  -- 'catalog_product', 'customer', 'catalog_category' etc.
    entity_model,
    entity_table,      -- Haupt-Entity-Tabelle (z.B. catalog_product_entity)
    value_table_prefix -- Präfix für Wert-Tabellen
FROM eav_entity_type
ORDER BY entity_type_id;

-- Alle Attribute eines Produkt-Entity-Typs
SELECT
    ea.attribute_id,
    ea.attribute_code,
    ea.frontend_label,
    ea.backend_type,    -- 'varchar', 'int', 'decimal', 'datetime', 'text', 'static'
    ea.frontend_input,  -- 'text', 'select', 'multiselect', 'boolean', 'textarea'
    ea.is_required,
    ea.is_user_defined, -- 1 = von Admin erstellt, 0 = Core-Attribut
    ea.is_searchable,
    ea.is_filterable,
    ea.is_visible_on_front,
    cat.used_in_product_listing
FROM eav_attribute ea
JOIN catalog_eav_attribute cat ON cat.attribute_id = ea.attribute_id
WHERE ea.entity_type_id = (
    SELECT entity_type_id FROM eav_entity_type WHERE entity_type_code = 'catalog_product'
)
ORDER BY ea.attribute_code;

-- EAV-Wert eines Produktattributs direkt lesen
-- Beispiel: 'name' (backend_type = 'varchar') für Produkt-ID 42
SELECT
    cpe.entity_id,
    cpe.sku,
    cpev.value   AS product_name,
    cpev.store_id
FROM catalog_product_entity cpe
JOIN catalog_product_entity_varchar cpev ON cpev.row_id = cpe.row_id
JOIN eav_attribute ea
    ON ea.attribute_id = cpev.attribute_id
    AND ea.attribute_code = 'name'
WHERE cpe.entity_id = 42
  AND cpev.store_id IN (0, 1)   -- 0 = global, 1 = store-spezifisch
ORDER BY cpev.store_id DESC     -- store-spezifischer Wert hat Vorrang
LIMIT 1;

4. Kunden: customer_entity, customer_address_entity

Kundenstammdaten liegen im EAV-Muster in customer_entity. Einfache skalare Attribute (E-Mail, Vorname, Nachname, Gruppe) sind als statische Spalten direkt in der Entity-Tabelle gespeichert, während komplexere Attribute in separaten Wert-Tabellen landen.

-- Top-Kunden nach Umsatz
SELECT
    ce.entity_id,
    ce.email,
    ce.firstname,
    ce.lastname,
    ce.group_id,           -- Kundengruppe
    ce.store_id,
    ce.is_active,
    ce.created_at,
    COUNT(so.entity_id)    AS order_count,
    MAX(so.created_at)     AS last_order_date,
    SUM(so.grand_total)    AS lifetime_value
FROM customer_entity ce
LEFT JOIN sales_order so
    ON so.customer_id = ce.entity_id
    AND so.state NOT IN ('canceled', 'closed')
GROUP BY ce.entity_id
ORDER BY lifetime_value DESC
LIMIT 20;

-- Kundenadressen zu einem Kunden
SELECT
    cae.entity_id,
    cae.parent_id,  -- = customer_entity.entity_id
    cae.firstname,
    cae.lastname,
    cae.street,
    cae.city,
    cae.postcode,
    cae.country_id,
    cae.telephone,
    cae.is_default_billing,
    cae.is_default_shipping
FROM customer_address_entity cae
WHERE cae.parent_id = 123;

5. CMS: cms_page, cms_block, cms_page_store

CMS-Inhalte werden in drei Tabellen verwaltet: cms_page für Seiten, cms_block für statische Blöcke, und die Zuordnungstabellen für die Store-Zuweisung. Ein CMS-Block kann mehreren Stores gleichzeitig zugeordnet sein.

-- Alle aktiven CMS-Seiten mit Store-Zuordnung
SELECT
    cp.page_id,
    cp.identifier,      -- URL-Slug z.B. 'about-us', 'privacy-policy'
    cp.title,
    cp.is_active,
    cp.page_layout,     -- z.B. '1column', '2columns-left'
    GROUP_CONCAT(cps.store_id ORDER BY cps.store_id) AS store_ids,
    cp.created_at,
    cp.update_time
FROM cms_page cp
JOIN cms_page_store cps ON cps.page_id = cp.page_id
WHERE cp.is_active = 1
GROUP BY cp.page_id
ORDER BY cp.identifier;

-- Statische CMS-Blöcke (für Template-Einbettung per )
SELECT
    block_id,
    identifier,
    title,
    is_active,
    creation_time,
    update_time
FROM cms_block
WHERE is_active = 1
ORDER BY identifier;

6. URL-Verwaltung: url_rewrite

Die Tabelle url_rewrite ist die zentrale Stelle für alle URLs im Shop. Sie enthält automatisch generierte URLs für Produkte und Kategorien sowie manuell angelegte Redirects. Bei großen Shops kann sie Millionen von Zeilen enthalten und ist oft ein Performance-Kandidat.

-- URL-Rewrite-Einträge für ein bestimmtes Produkt
SELECT
    url_rewrite_id,
    entity_type,       -- 'product', 'category', 'cms-page'
    entity_id,
    request_path,      -- z.B. 'mein-produkt.html'
    target_path,       -- z.B. 'catalog/product/view/id/42'
    redirect_type,     -- 0 = intern (kein Redirect), 301, 302
    store_id,
    is_autogenerated   -- 1 = automatisch, 0 = manuell
FROM url_rewrite
WHERE entity_type = 'product'
  AND entity_id = 42
ORDER BY store_id;

-- Größenübersicht und manuell erstellte Redirects
SELECT entity_type, redirect_type, COUNT(*) AS total_rows
FROM url_rewrite
GROUP BY entity_type, redirect_type
ORDER BY total_rows DESC;

-- Alle manuell erstellten 301-Redirects
SELECT request_path, target_path, redirect_type, store_id, description
FROM url_rewrite
WHERE is_autogenerated = 0 AND redirect_type IN (301, 302)
ORDER BY redirect_type, request_path;

7. Systemtabellen: setup_module, flag

Die Tabelle setup_module protokolliert den Installationsstand aller Module. Sie ist die Grundlage für bin/magento setup:upgrade: Magento vergleicht die aktuellen Modul-Versionen aus den module.xml-Dateien mit den gespeicherten Versionen und führt fehlende Migrationen aus.

-- Installierte Module und ihre Versionen
SELECT module, schema_version, data_version
FROM setup_module
WHERE module LIKE 'Magento_%'
ORDER BY module;

-- Module mit abweichenden Versionen (potentielle Upgrade-Kandidaten)
SELECT module, schema_version, data_version
FROM setup_module
WHERE schema_version != data_version
   OR schema_version IS NULL;

Die flag-Tabelle speichert System-Zustandsflags. Sie wird von Cron-Jobs, Indexern und anderen Systemkomponenten verwendet, um den letzten Ausführungszeitpunkt oder Zustände festzuhalten.

-- Alle System-Flags mit Zeitstempel
SELECT
    flag_id,
    flag_code,   -- z.B. 'config_hash', 'backend_caches', 'cron_schedules_cleaned'
    state,
    last_update
FROM flag
ORDER BY last_update DESC;

8. Berechtigungen: authorization_rule, authorization_role

Das Magento-Berechtigungssystem basiert auf Rollen (authorization_role) und Regeln (authorization_rule). Admin-Benutzer werden Rollen zugeordnet, Rollen erhalten Ressourcen-Berechtigungen nach dem allow/deny-Prinzip.

-- Alle Admin-Rollen mit Berechtigungsanzahl
SELECT
    ar.role_id,
    ar.role_name,
    ar.parent_id,
    COUNT(arule.rule_id) AS permission_count
FROM authorization_role ar
LEFT JOIN authorization_rule arule ON arule.role_id = ar.role_id
WHERE ar.role_type = 'G'    -- 'G' = Gruppe/Rolle, 'U' = Benutzer-spezifisch
GROUP BY ar.role_id
ORDER BY ar.role_name;

-- Alle erlaubten Ressourcen einer bestimmten Rolle
SELECT
    arule.resource_id,   -- z.B. 'Magento_Sales::actions'
    arule.permission     -- 'allow' oder 'deny'
FROM authorization_rule arule
JOIN authorization_role ar ON ar.role_id = arule.role_id
WHERE ar.role_name = 'Sales Manager'
  AND arule.permission = 'allow'
ORDER BY arule.resource_id;

-- Admin-Benutzer mit ihren Rollen
SELECT
    au.user_id,
    au.username,
    au.firstname,
    au.lastname,
    au.email,
    au.is_active,
    ar.role_name,
    au.last_login
FROM admin_user au
JOIN admin_user_role aur ON aur.user_id = au.user_id
JOIN authorization_role ar ON ar.role_id = aur.role_id
ORDER BY au.username;

9. Konfiguration lesen und schreiben per SQL

In der Praxis ist es manchmal notwendig, Konfigurationswerte direkt per SQL zu setzen – z.B. bei Deployment-Automatisierung, CI/CD-Pipelines oder wenn der Admin-Bereich nicht zugänglich ist. Das Scope-System muss dabei korrekt berücksichtigt werden.

-- Konfiguration auf Default-Ebene setzen (UPSERT-Pattern)
INSERT INTO core_config_data (scope, scope_id, path, value)
VALUES ('default', 0, 'catalog/seo/product_url_suffix', '.html')
ON DUPLICATE KEY UPDATE value = '.html';

-- Konfiguration auf Store-Ebene setzen (Store-ID 2)
INSERT INTO core_config_data (scope, scope_id, path, value)
VALUES ('stores', 2, 'general/locale/code', 'en_US')
ON DUPLICATE KEY UPDATE value = 'en_US';

-- Konfiguration auf Website-Ebene setzen (Website-ID 1)
INSERT INTO core_config_data (scope, scope_id, path, value)
VALUES ('websites', 1, 'web/secure/use_in_frontend', '1')
ON DUPLICATE KEY UPDATE value = '1';

-- Store-spezifische Konfiguration auf Default zurücksetzen
DELETE FROM core_config_data
WHERE path = 'general/locale/code'
  AND scope = 'stores'
  AND scope_id = 2;

-- Nach jeder SQL-Änderung an core_config_data:
-- bin/magento cache:flush
-- oder gezielt: bin/magento cache:clean config

10. Zusammenfassung

Die Magento Datenbank ist komplex, aber gut strukturiert. Wer die Kernprinzipien – Scope-basierte Konfiguration, Store-Hierarchie, EAV-Attributsystem, CMS-Speicherung und URL-Verwaltung – verinnerlicht hat, kann nahezu jede Frage über den Zustand des Systems direkt per SQL beantworten.

11. FAQ: Magento Datenbank Core-Tabellen