Dawit Girma

Posted on Feb 10

Entity-Attribute-Value (EAV) Model

#systemdesign #database #backend #architecture

(Example: Content Management System)

Have you ever faced a database design problem where the attributes of an entity vary widely across records?

If yes, this article is for you.

The Entity–Attribute–Value (EAV) model is a database design pattern that allows us to define entity attributes at runtime. In many real-world systems, a table can contain millions of records, where:

Some entities have attributes X, Y, Z
Others have completely different attributes
Many attributes apply only to a small subset of records

In such cases, using a traditional relational schema often leads to many NULL values and frequent schema changes.

With the EAV model, instead of adding new columns or storing NULLs, we define attributes separately and assign values only when they apply to a specific entity instance.

EAV models are commonly used in systems such as:

E-commerce platforms
Real-estate management systems
Content management systems (CMS)
Product catalogs

In this article, we will explain how the Entity–Attribute–Value model works by using a Content Management System (CMS) as a practical example.

Use Cases

The EAV model is powerful only when used in the right scenarios. Below are the main reasons to consider using EAV in your database design.

When to Use EAV

- Frequently changing attributes

When entities have many attributes that evolve over time (new attributes are added frequently).

- Sparse data

When most entities use only a small subset of available attributes, and the rest would otherwise be stored as NULL.

- Custom attributes

When administrators or users need to define custom attributes at runtime without requiring database schema changes.

When Not to Use EAV

- Stable and well-defined attributes

If the attributes are fixed and rarely change, a traditional relational schema is a better choice.

- High-performance requirements

EAV models often require multiple joins, which can negatively impact query performance.

- Complex reporting and analytics

Writing reports and analytical queries is more difficult and less efficient in EAV-based schemas.

Important note:

Using EAV does not mean every table in your system should follow this model.

In practice, the best approach is often a hybrid model, combining traditional tables with EAV tables based on the nature of each entity.

Prerequisites

Basic understanding of database systems
Familiarity with relational databases and ER diagrams

Project Setup

To illustrate the EAV model, we will design an Entity Relationship Diagram (ERD) for a simple content management system.

Understanding the EAV ERD

The classic EAV model consists of three main tables:

Figure 1.0: Entity–Attribute–Value ER Diagram

- Entity

Represents the main object whose attributes can vary over time.

- Attribute

Stores the possible attributes that an entity can have.

- AttributeValue

Stores the actual value of a specific attribute for a specific entity.

This structure allows attributes to be added dynamically without altering the database schema.

Example: Content Management System (CMS)

A Content Management System is used to create, manage, and publish different types of digital content such as:

Blog posts
Pages
Events
Courses
Job postings

Each content type has its own unique attributes. For example:

An Event has a location and start date
A Job has a salary and employment type
A Page may not require either

To support this flexibility without constant schema changes, the EAV model is an ideal solution.

Below is a simplified ERD for a CMS using the EAV model
(Note: This diagram may require refinement before production use).

Figure 1.1: EAV Model for a Content Management System

Tables Overview

- Content

Represents the actual content entity with dynamic attributes.

- ContentType

Defines the type of content (e.g., Blog, Event, Job).

- Attribute

Defines attributes specific to a content type.

- ContentAttributeValue

Stores the value of a specific attribute for a specific content item.

Real-World Table Instances

Table ContentType

Table Content

Table Attribute

Table ContentAttributeValue (Core table)

From these examples, you can clearly see how the EAV model allows different content types to store only the attributes that apply to them—without wasting space or changing the schema.

Implementation

The final step is implementing this model in a programming language or framework of your choice. This part is intentionally left to the reader, as covering it would significantly extend the length of this article.