There are two types of persistence models in Magento: simple and Entity–attribute–value (EAV). The term entity is tossed around interchangeably between the two types of models. We can think of an entity as any persistable model.

The Subscriber entity of the Magento_Newsletter module is an example of a simple model. We can see that it's comprised of the following:

• A model of type Magento\Newsletter\Model\Subscriber extends Magento\Framework\Model\AbstractModel
• A resource model of type Magento\Newsletter\Model\ResourceModel\Subscriber extends Magento\Framework\Model\ResourceModel\Db\AbstractDb
• A collection of type Magento\Newsletter\Model\ResourceModel\Subscriber\Collection extends Magento\Framework\Model\ResourceModel\Db\Collection\AbstractCollection

The Customer entity of the Magento_Customer module is an example of an EAV model. We can see that it's comprised of the following:

• A model of type Magento\Customer\Model\Customer extends Magento\Framework\Model\AbstractModel
• A resource model of type Magento\Customer\Model\ResourceModel\Customer extends Magento\Eav\Model\Entity\VersionControl\AbstractEntity
• A collection of type Magento\Customer\Model\ResourceModel\Customer\Collection extends Magento\Eav\Model\Entity\Collection\VersionControl\AbstractCollection

What differentiates EAV from simple models is essentially their resource model and collection classes. The resource model is our link to the database—our persistor, if you will.

When a subscriber is saved, its data gets saved horizontally in the database. Data from the subscriber model gets dumped into the single newsletter_subscriber table.

When a customer is saved, its data gets saved vertically in the database. Data from the customer model gets dumped into the following tables:

• customer_entity
• customer_entity_datetime
• customer_entity_decimal
• customer_entity_int
• customer_entity_text
• customer_entity_varchar

The decision as to where to store a value for an individual attribute is contained in the eav_attribute.backend_type column. The SELECT DISTINCT backend_type FROM eav_attribute; query reveals the following:

• The static attribute value gets stored in the <entityName>_entity table
• The varchar attribute value gets stored in the <entityName>_entity_varchar table
• The int attribute value gets stored in the <entityName>_entity_int table
• The text attribute value gets stored in the <entityName>_entity_text table
• The datetime attribute value gets stored in the <entityName>_entity_datetime table
• The decimal attribute value gets stored in the <entityName>_entity_decimal table

Next to the eav_attribute table, the remaining relevant information is scattered around the dozen of other eav_* tables, the most important being the eav_attribute_* tables:

• eav_attribute
• eav_attribute_group
• eav_attribute_label
• eav_attribute_option
• eav_attribute_option_swatch
• eav_attribute_option_value
• eav_attribute_set

The SELECT entity_type_code, entity_model FROM eav_entity_type; query indicates that the following Magento entities are from an EAV model:

• customer: Magento\Customer\Model\ResourceModel\Customer
• customer_address: Magento\Customer\Model\ResourceModel\Address
• catalog_category: Magento\Catalog\Model\ResourceModel\Category
• catalog_product: Magento\Catalog\Model\ResourceModel\Product
• order: Magento\Sales\Model\ResourceModel\Order
• invoice: Magento\Sales\Model\ResourceModel\Order\Invoice
• creditmemo: Magento\Sales\Model\ResourceModel\Order\Creditmemo
• shipment: Magento\Sales\Model\ResourceModel\Order\Shipment

However, not all of them use the EAV model to its full extent, as indicated by the SELECT DISTINCT entity_type_id FROM eav_attribute; query, which points only to the following:

• customer
• customer_address
• catalog_category
• catalog_product

What this means is that only four models in Magento Open Source really use EAV models for managing their attributes and storing data vertically through EAV tables. The rest are all flat tables, as all attributes and their values are in a single table.

The EAV models are inherently more complex to work with. They come in handy for cases where dynamic attribute creation is needed, ideally via an admin interface, as is the case with products. The majority of the time, however, simple models will do the job.