In order to understand what EAV is and what its role within Magento is, we need to
break down it into the parts of the EAV model.
• Entity: The entity represents the data items (objects) inside Magento
products, customers, categories, and orders. Each entity is stored in the
database with a unique ID.
• Attribute: These are our object properties. Instead of having one column per
attribute on the product table, attributes are stored on separates sets of tables.
• Value: As the name implies, it is simply the value link to a particular attribute.
This design pattern is the secret behind Magento’s flexibility and power, allowing
entities to add and remove new properties without having to do any changes to the
code or templates.
Whereas model can be seen as a vertical way of growing our database (new
attributes add more rows), the traditional model would involve a horizontal grow
pattern (new attributes add more columns) that would result in a schema redesign
every time new attributes are added.
The EAV model not only allows the fast evolution of our database, but also, it is
more efficient, because it only works with non-empty attributes, avoiding the need
to reserve additional space in the database for null values.
Adding a new product attribute is as simple as going to the Magento backend
and specifying the new attribute type, be it color, size, brand, and so on. The
opposite is also true, because we can get rid of unused attributes on our products
or customer models.
Magento Community Edition currently has eight different types of EAV objects:
• Customer address
• Product categories
• Credit memos
All this flexibility and power is not free, and there is a price to pay; implementing the
EAV model results in having our entity data distributed on a large number of tables,
for example, just the Product Model is distributed on around 40 different tables.
The following diagram only shows a few of the tables involved in saving the
information of Magento products:
Another major downside of EAV is the loss of performance when retrieving large
collections of EAV objects and an increase on the database query complexity.
Since the data is more fragmented (stored in more tables), selecting a single record
involves several joins.
Let’s continue using Magento products as our example and manually build the query
for retrieving a single product.
The first table that we will need to use is the catalog_product_entity. We can
consider this as our main product EAV table since it contains the main entity recordsfor our products:
Let’s query the table by running the following SQL query:
SELECT * FROM `catalog_product_entity`;
The table contains the following fields:
• entity_id: This is our product unique identifier and is used internally
• entity_type_id: Magento has several different types of EAV models,
products, customers, and orders, and these are just some of them. Identifying
each by type allows Magento to retrieve the attributes and values from the
• attribute_set_id: Products attributes can be grouped locally into attribute
sets. Attribute sets allow even further flexibility on the product structure
since products are not forced to use all available attributes.
• type_id: There are several different types of products in Magento: simple,
configurable, bundled, downloadable, and grouped products, each with
unique settings and functionality.
• sku: Stock Keeping Unit (SKU) is a number or code used to identify each
unique product or item for sale in a store. This is a user-defined value.
• has_options: This is used to identify if a product has custom options.
• required_options: This is used to identify if any of the custom options
• created_at: This is a row creation date.
• updated_at: This shows the last time the row was modified.
Now we have a basic understanding of the product entity table, and we also know
that each record represents a single product in our Magento store, but we don’t have
much information about that product beyond the SKU and the product type.
So, where are the attributes stored? And how does Magento know the difference
between a product attribute and a customer attribute?
For that, we need to take a look at the eav_attribute table by running the following
SELECT * FROM `eav_attribute`;
As a result, we will not only see the product attributes but also attributes
corresponding to the customer model, order model, and so on. Fortunately,
we already have a key for filtering the attributes from this table. Let’s run the
SELECT * FROM `eav_attribute`
WHERE entity_type_id = 4;
This query is telling the database to only retrieve the attributes where the
entity_type_id columns are equal to the product entity_type_id(4). Before
moving on, let’s analyze the most important fields inside the eav_attribute table:
• attribute_id: This is the unique identifier for each attribute and primary
key of the table.
• entity_type_id: This field relates each attribute to a specific EAV
• attribute_code: This field is the name or key of our attribute and is used to
generate the getters and setters for our magic methods.
• backend_model: The backend model manages loading and storing data into
• backend_type: This field specifies the type of value stored into the
• backend_table: This field is used to specify if the attribute should be stored
on a special table instead of the default EAV tables.
• frontend_model: The frontend model handles the rendering of the attribute
element into a web browser.
• frontend_input: Similar to the frontend model, the frontend input specifies
the type of input field the web browser should render.
• frontend_label: This field is the label/name of the attribute as it should be
rendered by the browser.
• source_model: The source models are used to populate an attribute with
possible values. Magento comes with several predefined