Назначение таблиц eav_


19

Я всегда задавался вопросом, в чем смысл таблиц:

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

Они всегда пусты. Они созданы в версиях до 1.6 app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.phpи позже, они перенесли в скрипт установки для версий 1.6+. /app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
Я видел, что существует модель ресурсов, связанная с одной из таблиц Mage_Eav_Model_Resource_Entity_Store(может быть, есть другие), но с ней ничего не происходит.

Есть ли какая-либо польза для этих таблиц или это другая «функция», которая была запущена и не реализована, как, например, версия макета или хлебные крошки администратора .


3
Когда я начал изучать Magento и особенно EAV, я вижу, что эти таблицы всегда пусты. Я пытался искать в Интернете, но так и не получил определенного ответа. Я подумал, что это может быть определение или справочная таблица для других таблиц сущностей. Но сейчас я тоже с нетерпением жду ответа. Спасибо за этот вопрос. :)
MagentoBoy

@MagentoBoy. Я также видел тогда, когда я начал работать с Magento, когда я пытался обернуть голову вокруг базы данных. Я был 5+ лет, и я все еще озадачен.
Мариус

... но вы, ребята, действительно обладаете хорошими навыками в magento .. Иногда я использую ваши ссылки, чтобы учиться и в своем коде. Это было от 7 до 8 месяцев для magento и 11 месяцев для опыта php, но все еще чувствую, что я Я новичок в magento и должен много учиться ..
MagentoBoy

Ответы:


17

Я предполагаю, что это отчасти наследие и «удобный» шаблон для разработчиков для реализации «общих» сущностей / моделей.

Как вы сказали, связанные таблицы обычно пусты. Причина в том, что ни один из основных объектов EAV не использует эту структуру таблицы объектов по умолчанию. Это таблицы сущностей из установки 1.8:

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)

Используя модель Customer в качестве примера, мы видим, что модель ресурсов Mage_Customer_Model_Resource_Customerрасширяется Mage_Eav_Model_Entity_Abstract, Source .

Примечание . До версии 1.6 модель ресурса для сущности клиента Mage_Customer_Model_Entity_Customerтакже была расширена Mage_Eav_Model_Entity_Abstract, Source .

Если мы рассмотрим Mage_Eav_Model_Entity_Abstractкласс, мы найдем getEntityTableметод. Этот метод используется, чтобы определить, какую таблицу использовать при построении запросов во время обычных операций CRUD. Другой метод, который представляет интерес getValueTablePrefix. Он определяет префикс для таблиц для данных таблиц «типа», *_datetime, *_decimal, *_varcharи так далее.

Заглянуть в источник этих методов ( здесь и здесь ).

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;
    }

В приведенном выше методе мы можем видеть, что если тип сущности не определяет пользовательскую таблицу, то по умолчанию используется Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE. Значение этой константы равно значению 'eav/entity', которое в свою очередь превращается в eav_entityтаблицу (при условии, что в приложении нет настроенного префикса таблицы). Второй метод, который я упомянул, использует эту таблицу в качестве префикса, если ни один из них не был настроен для данного объекта. Если вы изучите значения в eav_entity_typeтаблице для value_table_prefixстолбца, вы заметите, что они все 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;
    }

Логика метода довольно проста: если префикс значения не определен, используйте имя таблицы сущностей в качестве префикса.

Я предполагаю, что, поскольку эти таблицы были в Magento так долго, лучше оставить их для какой-либо обратной совместимости, чем полностью удалить их. Идея, которую, я полагаю, они преследовали, заключалась в простой в использовании структуре сущности / модели, которую другие разработчики могли бы просто расширить на несколько классов и иметь эти «динамические» атрибуты, которые можно изменить через администратора (см. Каталог продуктов и моделей клиентов). К сожалению, реализация и практика указанного паттерна, кажется, плохо масштабируются и приводят к проблемам. Я никогда не видел, чтобы эта структура использовалась в дикой природе, вероятно, из-за отсутствия документации и примеров использования или низкой производительности.

Я не ведущий разработчик (или археолог), но это то, что я извлекаю из кода и структур данных, надеюсь, это поможет пролить некоторый свет.


1
Спасибо за объяснение. Достаточно хорошо для меня. Я постараюсь сделать сущность, которая использует эти таблицы, просто для удовольствия.
Мариус

6

Рассмотрим этот фрагмент кода в базовой модели ресурсов EAV.

#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;
}

Этот метод извлекает имя таблицы базовых сущностей для хранения. Таким образом, для модели ресурсов продукта этот метод вернется catalog_product_entity(при условии, что префикс имени таблицы не был установлен)

Эти четыре строки являются наиболее показательными.

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

Если у сущности нет таблицы, используется следующая константа

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

Эта eav/entityстрока затем используется для поиска имени таблицы

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

Который извлекает имя таблицы из конфига.

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

Ах, ха! Если тип сущности eav не имеет установленного имени таблицы, то Magento будет использовать eav_entityтаблицы в качестве места хранения по умолчанию.

Изначально команда инженеров Magento была очарована концепцией EAV - в то время как современный Magento сократил этот показатель, модели EAV стали предпочтительным решением для многих проблем.

Представляется разумным предположить / предположить, что первоначальная предварительная реализация EAV хранила все данные в этой центральной eav_entityтаблице типов (общий шаблон на корпоративных платформах), а типы сущностей появились позже.

Еще одна (неотразимая) возможность - эта функция была предназначена для включения «бесстольных» моделей CRUD. Теоретически, можно было бы вставить правильную информацию о типе EAV, настроить классы модели / ресурса / коллекции и сохранить данные в этих eav_entityтаблицах. Отказ Magento от EAV, а также внимание инженера-проектировщика к функциям конечных пользователей после запуска означало, что эта функция исчезла в тумане. Хотя мне было бы любопытно, сработает ли это, я бы не хотел на это полагаться, поскольку этому пути кода не уделялось много внимания, и сомнительно, что TAF охватывает его использование.


1
Спасибо за подробное объяснение. Я определенно собираюсь попробовать построить модуль с «безбольным» объектом, чтобы увидеть, работает ли он. +1 от меня. Но я чувствую себя обязанным принять ответ, предоставленный @beeplogic, в котором говорится, в основном, то же самое. Он был на 5 минут быстрее.
Мариус

-1

Magento использует модель данных под названием «Значение атрибута сущности» для многих своих функций (клиенты, продукты и т. Д.). Это то, что позволяет динамические атрибуты в системе без необходимости реструктурировать и изменять таблицы на лету. EAV В Википедии


Спасибо, но это не совсем отвечает на вопрос. Какой субъект использует таблицы, упомянутые в вопросе? Я не говорил о клиенте, продуктах или категориях.
Мариус
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.