Question

What is the main difference between Row Modelling and EAV (Entity-Atribute-Value)?

I think EAV is a subset of Row Modelling but I cant state the main differences.

If possible, please use references in your answers.

Answer 1

Good question.

According to the Wikipedia article,

The differences between row modeling and EAV are:

• A row-modeled table is homogeneous in the facts that it describes: a Line Items table describes only products sold. By contrast, an EAV table contains almost any type of fact.
• The data type of the value column/s in a row-modeled table is pre-determined by the nature of the facts it records. By contrast, in an EAV table, the conceptual data type of a value in a particular row depend on the attribute in that row.

So here’s my take on that:

• row modelling

  create table line_items (
    id int primary key,
    sale_id int,
    foreign key sale_id references sale(id),
    product_name varchar(50), -- this could also be a foreign key 
    price decimal(10, 2)
  );
  

  • this has some type safety: price can’t be some junk string

  • the only things that we put in this table are line items

  • to me, this sounds just like a normal 1:many relationship (but I’m not sure so don’t quote me on that)

• entity-attribute-value

  create table my_eav (
    entity_id int,
    foreign key (entity_id) references entity(id),
    attribute varchar(50),
    value varchar(50),
    primary key (entity_id, attribute)
  );
  

  • the values are stored as varchars — but they could be numbers, strings, times, etc.

  • all kinds of data can be stored — shoe size, airplane weight, the number of home runs Babe Ruth hit in 1926

---

The article goes on to say:

The circumstances where you would need to go beyond standard row-modeling to EAV are listed below:

• The data types of individual attributes varies (as seen with clinical findings).
• The categories of data are numerous, growing or fluctuating, but the number of instances (records/rows) within each category is very small. Here, with conventional modeling, the database’s entity–relationship diagram might have hundreds of tables: the tables that contain thousands/ millions of rows/instances are emphasized visually to the same extent as those with very few rows. The latter are candidates for conversion to an EAV representation.

So if you have a lot of these 1:many relationships, do you want to have 1 table for each, as row modelling requires? Whereas EAV would allow you to combine (some or all of) those tables into 1.