Overview Of Magento2 EAV Attribute
Last week, we took a look into Magento tutorial 18 – how to override core files in Magento and learned overriding principle in Magento as well as overriding model class, helper class and resource model in Magento.
Now, to keep on our Magento tutorial series, we will discover Entity Attribute Value (EAV) in Magento. Lesson 19 will cover three sections and last for three hours:
- EAV Model
- Working with EAV Model
- Working with collections and EAV collections in Magento
1. EAV Model
What is Entity Attribute Value:
In common sense, Entity Attribute Value model is a data model to describe entities where the number of attributes (properties and parameters) which can be used to describe them are potentially vast, but the number of attributes which will actually apply to a given entity are relatively modest.
In mathematics, this model is known as a sparse matrix. EAV is also known as object–attribute–value model, vertical database model and open schema.
There are certain cases where an EAV schematic is an optimal approach to data modelling for a problem domain. However, in many cases where data can be modelled in statically relational terms an EAV based approach is an anti-pattern which can lead to longer development times, poor use of database resources and more complex queries when compared to a relationally-modelled data schema.
In Magento, EAV stands for Entity, Attribute and Value. Let’s look into each part and try to understand them a little better.
Entity:The entity represents Magento data items such as products, categories, customers and orders. Each entity (product, category, etc.) will have its own entity record in the database.
Attribute:The attributes represent data items that belong to an entity. For example, the product entity has attributes such as name, price, status and many more.
Value: The value is the simplest to understand as it is simply a value linked to an attribute. For better understanding, let’s consider the product entity. Each product entity will have a series of attributes, one of them is the name attribute. Each product will then have a value for the name attribute (and all other attributes). This might not be clear yet but keep on reading!
Entity table structure
This data representation is analogous to space-efficient methods of storing a sparse matrix, where only non-empty values are stored. In an EAV data model, each attribute-value pair is a fact describing an entity, and a row in an EAV table stores a single fact. EAV tables are often described as “long and skinny”: “long” refers to the number of rows, “skinny” refers to the few columns.
Data is recorded as three columns:
- entity:The item being described.
- The attribute or parameter: A foreign key into a table of attribute definitions. At the very least, the attribute definitions table would contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation, e.g., maximum string length and regular expression, set of permissible values, etc.
- The value of the attribute: An attribute is a property of a product, for example, the product color, the size, or the description. Some attributes are built into the system by default, and others can be created to address specific needs. You can add, edit, or remove product attributes in Magento 2 to customize your products. Attribute sets
. Why is Entity Attribute Value used
EAV is used because it is much more scalable than the usual normalised database structure. Developers can add attributes to any entity (product, category, customer, order etc) without modifying the core database structure. When a custom attribute is added, no logic must be added to force Magento to save this attribute because it is already built into the model; as long as the data is set and the attribute has been created, the model will be saved
What is the downside of EAV
A major downside of EAV is its speed. With entity data being so fragmented, creating a whole entity record requires a lot of expensive table joins. Fortunately, the team at Varien have implemented an excellent cache system, allowing developers to cache information that doesn’t often change.
Another problem with EAV is its learning curve, which means that a lot of junior developers give up before they can truly see the simplicity of it. While there is no quick fix for this, hopefully this article will help people start overcoming this problem.
Working with EAV Model
The Achilles heel of Entity Attribute Value is the difficulty of working with large volumes of EAV data. It is often necessary to transiently or permanently inter-convert between columnar and row-or EAV-modeled representations of the same data. This can be both error-prone if done manually as well as CPU-intensive. Generic frameworks that utilize attribute and attribute-grouping metadata address the former but not the latter limitation; their use is more or less mandated in the case of mixed schemas that contain a mixture of conventional-relational and EAV data, where the error quotient can be very significant.
Obviously, no matter what approaches you take, querying EAV will never be as fast as querying standard column-modeled relational data, in much the same way that access of elements in sparse matrices are not as fast as those on non-sparse matrices if the latter fit entirely into main memory. (Sparse matrices, represented using structures such as linked lists, require list traversal to access an element at a given X-Y position, while access to elements in matrices represented as 2-D arrays can be performed using fast CPU register operations.). If, however, you chose the EAV approach correctly for the problem that you were trying to solve, this is the price that you pay; in this respect, EAV modeling is an example of a space (and schema maintenance) versus CPU-time tradeoff.
How Entity Attribute Value data storage work in Magento
The EAV data storage in Magento seems quite complicated with the separated data for each store. There are some data storage tables:
- TABLE EAV entity type:stores the entity type including the information of model for the entity or the default attribute set.
EAV entity:Contains an eav_entity table storing objects of a certain entity type
EAV entity attribute:Attributes are divided into groups (one group may have a lot of attributes and one attribute may be in a lot of groups). An attribute set includes the number of groups. An object has an attribute set.
EAV entity value:Magento optimizes the data storage by providing value tables corresponding to the data types such as: eav_entity_datetime, eav_entity_varchar, eav_entity_int
Entity Attribute Value data access process in Magento
Exporting EAV data requires querying continuously from many tables, so model carries out mapping data on many database tables.
- Read data:To read data from database to object, model needs to follow these steps:
- Read data from main table or entity table
- Define set of object attributes
- Read out values of attributes for objects
- Change values of attributes
- Map data in object
- Burn data:Burning EAV data to database process as follows:
- Get data mapped in the objects
- Change the values of attributes
- Save data in main table or entity table
- Save data in values of attributes table
Conclusion:
Entity-Attribute-Value (EAV) is a data modeling technique used in database systems to handle flexible and dynamic data structures. While EAV offers certain advantages in terms of flexibility and extensibility, it also introduces several challenges and trade-offs.
EAV allows for storing data in a generic structure, where each attribute-value pair is associated with an entity. This flexibility makes it possible to add new attributes without altering the underlying database schema. It is particularly useful in scenarios where the attributes are dynamic or vary significantly between entities.
In conclusion, while EAV can provide flexibility and adaptability in handling dynamic data structures, it is essential to carefully consider the trade-offs and challenges associated with its implementation. Organizations should evaluate their specific requirements, data access patterns, and performance considerations before deciding to adopt an EAV-based approach. Alternative data modeling techniques should also be explored to ensure the most suitable solution for the given use case.