The EAV system is one of the most complex part of Magento shop software.
It is also the most controversial and often cited as a root of performance problems in shops that have to handle large and complex product databases.
When developing Magento extensions these problems can be exacerbated by failure to properly use the EAV implemented in Magento, which often happens due to a great effort that is required to understand it.
Some of its earliest applications were storage systems for clinical data back in 1970s.
As a storage method EAV borrows from early object-oriented languages
Functional languages such as LISP/SIMULA 67 are also known to have contributed to the development of EAV. They contain storage structures that record object information in attribute-value pairs – a principle fundamental to EAV.
The most widely used way to store entities is implementing attributes as columns and entities as rows. This is sufficient for most tasks and has been efficiently implemented in relational databases. However, if you work with entities that have a large or variable, or large and variable, number of attributes, columnar representation becomes difficult. MySQL, for instance, has a hard limit of 4096 columns per table. Oracle has even less: 1000. Microsoft SQL Server offers up to 30,000 columns. But what if you must deal with entities that have many hundred thousands of possible attributes? And what if each entity has only a few attributes with values?
EAV generalizes row modelling by saving all entity attributes in one or several tables, which store data in attribute-value pairs. EAV becomes especially useful when the following conditions are present:
1.Entity attributes vary significantly in terms of data type
2.The number of possible entity types is huge, and entity types have individual sets of attributes; even if the number of attributes in every set is relatively small.
3.Some attributes are common to all (or at least some) entity types, while other are individual and sparse.