Magento数据库结构EVA
Magento的数据库结构：EVA(实体-属性-值)
实体，属性和值（EVA）数据库架构排在第一，非常难以把握。EVA结构缺少文档，大部分的人还不知道EVA结构的，对magento都的好处、重要性以及适合性。在这篇文章我要介绍EVA是怎么工作的，为什么他有效，看了这边文章对magento的开发者来说是很有好处的。为了更好的理解这边文章，我建议使用phpmyadmin等数据库工具。
1、什么是EVA
EVA代表实体，属性和价值。让我们看看它的每一部分，试着更好的了解它。
实体
实体代表等产品，种类，客户和订单Magento的数据项。每个实体（产品，类别等）都会有它的数据库中的实体记录。
属性
该属性表示数据项属于一个实体。例如，产品实体，如名称，价格，地位和更多的属性。
值
该值是最简单的理解，因为它是简单地链接到一个属性的值。
为了更好地理解这一点，让我们考虑产品的实体。每个产品的实体将有一个属性，一个是属性名称系列。每一种产品将有一个属性名称值（和所有其他属性）。
这可能还不太清楚，但请继续阅读！
EVA是怎么工作的？
在Magento之前，数据库似乎简单很多。如果你在设计一个电子商务应用程序，你有一个表中包含您的产品的所有信息，另一个含有您的分类信息，也许另一个表连接这两个在一起。这是很简单易懂，而magento 产品和目录就大约有40个表。为了了解原因，让我们用一个产品表作为例子。比起将所有的数据存取在一个表格中，magneto将信息分开存储在多张表格中。
在这种层次结构的顶部表是?catalog_product_entity. 如果你在phpMyAdmin看看这个表，你会看到它包含了产品的简单基本资料，也没有出现任何有用的信息，包括SKU！幸运的是，使用此表是有可能建立从属性和值表的完整的产品记录。
要开始构建一个完整的产品记录，您将需要开始加入到产品实体的属性表。你这样做之前，
看一下名为eav_attribute的表。eav_attribute是存储属性的主要表，用于存储所有不同的实体的属性（产品，客户，订单，分类等）。在phpMyAdmin打开此表，并点击浏览。请注意，现在有数百个不同的属性，有些甚至使用相同的名字？起初，这个困惑我，因为我不知道Magento怎么可以区分所谓的这两个属性。Magento的怎么知道哪一个属性属于一个产品，或者属于一个类别？由于通常是与Magento情况下，一个小研究使我得出的一个非常简单的答案：entity_type_id！每一个实体(产品，客户，订单，分类等) 都有一个entity_type_id.要了解这一点，回去catalog_product_entity 查找entity_type_id 这个字段.在该表中每个记录的值应该是4，因为这已被列为指定产品entity_type_id。如果你看看
catalog_category_entity你将看到另一个不同的entity_type_id。使用这个值和属性代码，它可以为一个产品或任何实体加载属性。
考虑下面的查询
1
# Load all product attributes
SELECT attribute_code FROM eav_attribute
WHERE entity_type_id = 4;
# Load a single product attributes
SELECT attribute_code FROM eav_attribute
WHERE entity_type_id = 4 AND attribute_code = 'name';
Now that you can get attributes and entities, it is time to start getting values. Values are separated across several different tables for reasons that I will go into shortly. For now though, just take a look at all tables that begin with catalog_product_entity. The way the values are split depends upon their type. For example, all prices and other decimal attributes are stored in catalog_product_entity_decimal where as all short text strings are stored in
catalog_product_varchar. To figure out which table each attribute is stored in, Magento uses the column backend_type in the table eav_attribute. If you run the following query you should be able to find out the backend type for the product attribute ‘name’.
1
SELECT attribute_code, backend_type FROM eav_attribute
WHERE entity_type_id = 4 AND attribute_code = 'name';
Hopefully the above query returned the backend_type varchar, which is the correct type for name and all other short text strings. Based on what was said above, we can determine that the value for the name attribute will be stored in catalog_product_entity_varchar. What do you think will be produced by the following query? Have a think and then copy it into phpMyAdmin and see whether you’re right.
SELECT e.entity_id AS product_id, var.value AS product_name
FROM catalog_product_entity e, eav_attribute eav, catalog_product_entity_varchar var WHERE
e.entity_type_id = eav.entity_type_id
AND eav.attribute_code = 'name'
AND eav.attribute_id = var.attribute_id
AND var.entity_id = e.entity_id
The above code lists out the name and id for every product in your database. If you got that correct then congratulations, you are well on your way to understanding the EAV architecture. If you didn’t get that, keep going and then give this another read afterwards. If you’re still confused, post your questions in the comments or email me and I’ll try to make things clearer. If you did understand that, can you see how using a simple PHP loop, you could cycle through all product attributes and retrieve each value, creating a full product model?
If you’re running a multi-store Magento, here is how to adapt the above code to only include products from a certain store.
SELECT e.entity_id AS product_id, var.value AS product_name
FROM catalog_product_entity e, eav_attribute eav, catalog_product_entity_varchar var WHERE
e.entity_type_id = eav.entity_type_id
AND eav.attribute_code = 'name'
AND eav.attribute_id = var.attribute_id
AND var.entity_id = e.entity_id
AND var.store_id = 0
为什么要使用EVA?
EAV 是因为它比一般规范化的数据库结构扩展性更好。开发人员无需修改数据库结构的核心就可以为任何实体（产品，品类，客户，订单等）添加属性。当建立一个自定义属性的时候，不用为保存这个属性去建立逻辑结构，因为它已经被建立到数据库模型中；只要数据集和属性已经建立，该模型将被保存！
EAV的缺点是什么?
EAV一个主要缺点是它的速度。因为实体数据如此支离破碎，创造了整个实体记录需要大量的表联接。幸运的是，在瓦瑞恩团队有一个很好的缓存系统实施，允许开发者缓存不经常改变的资料。
EAV的另一个问题是它学习有曲线性, 这样很多初级开发人员在了解到它的的简单之前就已经放弃了。虽然没有此快速修复，希望这篇文章将有助于人们开始解决这个问题。
结论
实体，属性，价值是一个伟大的数据库结构，是Magento成功的一个关键部分，开发人员了解如何运作是非常重要的。