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