Supongo que es parte del legado y un patrón de "conveniencia" para que los desarrolladores implementen entidades / modelos "genéricos".
Como has dicho, las tablas relacionadas generalmente están vacías. La razón es que ninguna de las entidades centrales de EAV utiliza esta estructura de tabla de entidades "predeterminada". Estas son las tablas de entidades de una instalación 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)
Usando el modelo del Cliente como ejemplo, podemos ver que el modelo de recurso se Mage_Customer_Model_Resource_Customer
extiende Mage_Eav_Model_Entity_Abstract
, Fuente .
Nota : Antes de 1.6, el modelo de recursos para la entidad del cliente era el Mage_Customer_Model_Entity_Customer
que también se extendía Mage_Eav_Model_Entity_Abstract
, Fuente .
Si examinamos la Mage_Eav_Model_Entity_Abstract
clase, encontramos un getEntityTable
método. Este método se utiliza para determinar qué tabla usar al generar consultas durante operaciones CRUD comunes. Otro método que es de interés es getValueTablePrefix
. Se determina el prefijo para las tablas de datos para las tablas de "tipo", *_datetime
, *_decimal
, *_varchar
y así sucesivamente.
Asomarse a la fuente de esos métodos ( aquí y aquí ).
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;
}
En el método anterior, podemos ver que si el tipo de entidad no define una tabla personalizada, su valor predeterminado es Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE
. El valor de esa constante es 'eav/entity'
, que a su vez se convierte en la eav_entity
tabla (suponiendo que no haya un prefijo de tabla configurado en la aplicación). El segundo método que mencioné recae en esta tabla como un prefijo si no se ha configurado ninguno para la entidad dada. Si examina los valores en la eav_entity_type
tabla paravalue_table_prefix
columna, notará que son todos 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;
}
La lógica en el método es bastante simple, si no se define un prefijo de valor, use el nombre de la tabla de entidad como prefijo.
Supongo que, dado que estas tablas han estado en Magento durante tanto tiempo, es mejor dejarlas para cualquier compatibilidad con versiones anteriores que eliminarlas por completo. La idea que creo que buscaban era una estructura de entidad / modelo fácil de usar que otros desarrolladores podrían simplemente extender algunas clases y tener estos atributos "dinámicos" que podrían cambiarse a través del administrador (consulte el catálogo de productos y modelos de clientes). Lamentablemente, la implementación y la práctica de dicho patrón no parece escalar bien y genera problemas. Nunca he visto esta estructura utilizada en la naturaleza, probablemente debido a la falta de documentación y ejemplos de casos de uso o bajo rendimiento.
No soy un desarrollador central (o arqueólogo), pero eso es lo que deduzco del código y las estructuras de datos, espero que ayude a arrojar algo de luz.