Der Zweck von 'eav_'-Tabellen

Ich habe mich immer gefragt, was die Tabellen bedeuten:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Sie sind immer leer. Sie wurden in Versionen vor 1.6 in erstellt app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpund später im Installationsskript für die Versionen 1.6+ ausgeführt. /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
Ich habe gesehen, dass mit einer der Tabellen ein Ressourcenmodell verknüpft ist Mage_Eav_Model_Resource_Entity_Store(möglicherweise gibt es andere), aber nichts passiert damit.

Gibt es irgendeine Verwendung für diese Tabellen oder handelt es sich um eine andere "Funktion", die gestartet und nicht implementiert wurde, wie zum Beispiel die Layout-Version oder Admin-Breadcrumbs .

Ich vermute, es ist Teil des Erbes und ein "Bequemlichkeitsmuster" für Entwickler, "generische" Entitäten / Modelle zu implementieren.

Wie Sie angegeben haben, sind die zugehörigen Tabellen normalerweise leer. Der Grund dafür ist, dass keine der EAV-Kernentitäten diese "Standard" -Entitätstabellenstruktur verwendet. Dies sind die Entitätstabellen aus einer 1.8-Installation:

mysql> select distinct(entity_table) from eav_entity_type;
+-------------------------+
| entity_table            |
+-------------------------+
| customer/entity         |
| customer/address_entity |
| sales/order             |
| sales/order_entity      |
| catalog/category        |
| catalog/product         |
| sales/quote             |
| sales/quote_address     |
| sales/quote_entity      |
| sales/quote_item        |
| sales/invoice           |
+-------------------------+
11 rows in set (0.00 sec)

Am Beispiel des Kundenmodells können wir sehen, dass sich das Ressourcenmodell Mage_Customer_Model_Resource_Customererweitert Mage_Eav_Model_Entity_Abstract, Quelle .

Hinweis : Vor dem 1.6 das Ressourcenmodell für die Kunden Unternehmen wurde Mage_Customer_Model_Entity_Customerdie ebenfalls erweitert Mage_Eav_Model_Entity_Abstract, Quelle .

Wenn wir die Mage_Eav_Model_Entity_AbstractKlasse untersuchen, finden wir eine getEntityTableMethode. Mit dieser Methode wird bestimmt, welche Tabelle beim Erstellen von Abfragen bei allgemeinen CRUD-Operationen verwendet werden soll. Eine andere Methode, die von Interesse ist, ist getValueTablePrefix. Er bestimmt das Präfix für die Tabellen für Daten „Typ“ Tabellen *_datetime, *_decimal, *_varcharund so weiter.

Ein Blick in die Quelle für diese Methoden ( hier und hier ).

public function getEntityTable()
    {
        if (!$this->_entityTable) {
            $table = $this->getEntityType()->getEntityTable();
            if (!$table) {
                $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
            }
            $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
        }

        return $this->_entityTable;
    }

In der obigen Methode wird angezeigt, dass der Entitätstyp standardmäßig keine benutzerdefinierte Tabelle definiert Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. Der Wert dieser Konstante wird 'eav/entity'wiederum in die eav_entityTabelle umgewandelt (vorausgesetzt, die Anwendung enthält kein konfiguriertes Tabellenpräfix). Die zweite von mir erwähnte Methode greift auf diese Tabelle als Präfix zurück, wenn für die angegebene Entität keine konfiguriert wurde. Wenn Sie die Werte in der eav_entity_typeTabelle für die value_table_prefixSpalte untersuchen, werden Sie feststellen, dass sie alle sind NULL.

public function getValueTablePrefix()
    {
        if (!$this->_valueTablePrefix) {
            $prefix = (string)$this->getEntityType()->getValueTablePrefix();
            if (!empty($prefix)) {
                $this->_valueTablePrefix = $prefix;
                /**
                * entity type prefix include DB table name prefix
                */
                //Mage::getSingleton('core/resource')->getTableName($prefix);
            } else {
                $this->_valueTablePrefix = $this->getEntityTable();
            }
        }

        return $this->_valueTablePrefix;
    }

Die Logik in der Methode ist ziemlich einfach, wenn kein Wertpräfix definiert ist, verwenden Sie den Namen der Entitätstabelle als Präfix.

Ich nehme an, dass es das Beste ist, diese Tabellen aus Gründen der Abwärtskompatibilität zu belassen, als sie sofort zu entfernen, da sie schon so lange in Magento sind. Die Idee, für die sie sich entschieden haben, war meines Erachtens eine benutzerfreundliche Entity / Model-Struktur, die andere Entwickler einfach um einige Klassen erweitern konnten und über diese "dynamischen" Attribute verfügten, die über den Administrator geändert werden konnten (siehe Katalogprodukte und Kundenmodelle). Leider scheint die Implementierung und Praxis dieses Musters nicht gut zu skalieren und führt zu Problemen. Ich habe diese Struktur noch nie in freier Wildbahn gesehen, wahrscheinlich aufgrund fehlender Dokumentation und fehlender Anwendungsbeispiele oder mangelnder Leistung.

Ich bin kein Hauptentwickler (oder Archäologe), aber das ist es, was ich aus dem Code und den Datenstrukturen zusammengetragen habe.

Betrachten Sie dieses Codebit im Basis-EAV-Ressourcenmodell.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
public function getEntityTable()
{
    if (!$this->_entityTable) {
        $table = $this->getEntityType()->getEntityTable();
        if (!$table) {
            $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
        }
        $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
    }

    return $this->_entityTable;
}

Diese Methode ermittelt den Namen der Basisentitätstabelle, die für die Speicherung verwendet werden soll. Für das Ressourcenmodell eines Produkts wird diese Methode zurückgegeben catalog_product_entity(vorausgesetzt, es wurde kein Präfix für den Tabellennamen festgelegt).

Diese vier Zeilen sind die aufschlussreichsten.

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
$table = $this->getEntityType()->getEntityTable();
if (!$table) {
    $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
}

Wenn für die Entität keine Tabelle festgelegt ist, wird die folgende Konstante verwendet

#File: app/code/core/Mage/Eav/Model/Entity.php
const DEFAULT_ENTITY_TABLE      = 'eav/entity';

Diese eav/entityZeichenfolge wird dann zum Nachschlagen eines Tabellennamens verwendet

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
Mage::getSingleton('core/resource')->getTableName($table);

Welches pflückt den Tabellennamen aus der Konfig.

<!-- File: app/code/core/Mage/Eav/etc/config.xml -->
<entity>
    <table>eav_entity</table>
</entity>

Ah ha! Wenn für einen eav-Entitätstyp kein Tabellenname festgelegt ist, verwendet Magento die eav_entityTabellen als Standardspeicherort.

Das ursprüngliche Magento-Entwicklungsteam war von dem EAV-Konzept begeistert - während das moderne Magento dies zurückgefahren hat, waren EAV-Modelle die bevorzugte Lösung für viele Probleme.

Es erscheint vernünftig anzunehmen / zu spekulieren, dass die ursprüngliche EAV-Implementierung vor der Veröffentlichung alle Daten in dieser zentralen Typentabelle gespeichert hat eav_entity(ein in Unternehmensplattformen übliches Muster), und die Entitätstypen kamen später hinzu.

Eine andere (zwingende) Möglichkeit ist, dass diese Funktion "tableless" CRUD-Modelle ermöglichen soll. Theoretisch wäre es möglich, die richtigen EAV-Typinformationen einzufügen, Ihre Modell- / Ressourcen- / Erfassungsklassen einzurichten und Daten in diesen eav_entityTabellen zu speichern . Die Abkehr von Magento von EAV und die Konzentration des Entwicklungsteams auf Endbenutzerfunktionen nach dem Start führten dazu, dass diese Funktion im Nebel verschwand. Ich wäre zwar neugierig, ob dies funktioniert, möchte mich aber nicht darauf verlassen, da es sich nicht um einen Codepfad handelt, dem viel Aufmerksamkeit geschenkt wird, und es ist zweifelhaft, ob der TAF seine Verwendung abdeckt.

Magento verwendet für viele seiner Funktionen (Kunden, Produkte usw.) ein Datenmodell mit dem Namen "Entity Attribute Value". Dies ermöglicht dynamische Attribute im System, ohne dass die Tabellen im laufenden Betrieb neu strukturiert und geändert werden müssen. EAV Auf Wikipedia