DB Structure: one table to hold all domain values? [duplicate]

Question

This question already has answers here:

Is there a name for this database schema of key values? (5 answers)

Closed 1 year ago.

One database I recently start working with was designed with one main table containing all possible values, and foreign keys in other tables are specifying the nature of each of those items.

CREATE TABLE entity
(
     indexid INTEGER PRIMARY KEY NOT NULL,
     entitytype INTEGER,
     entityname VARCHAR,
);

For example, this main table contain a field named 'entityname' possibly containing records such as:

• the upc code of the item
• the short name of the item
• the long name of the item
• the location of the item
• the vendor for this item
• the quantity in stock
• (and many others)

Each record in this table got a entitytype number as a foreign key referring in another table what each records mean, such as

entitytype=10 mean that this entity is a UPC code type, and then

entitytype=12 mean that this entity is a vendor name type, etc...

Obviously there is dozen of such types for entities.

I feel like it is a bit unintuitive. There is this post here (See One table to hold all domain values section) where the author suggest the approach as I expressed it in my example may not be the best way to do this, and I would tend to agree with his opinion on the matter.

I also think it is difficult to make efficient queries, and I feel it is not how this should be done. I would rather have more tables and keep the whole more intuitive. I have a time window where I could redesign this and was thinking about long term and best practices.

So can this approach be considered a good practice in the long term and I just need to deal with it?

Answer 1

That design structure is commonly referred to as entity-attribute-value, or EAV. Some people hate it, others see the inherent beauty in its design. There is nothing wrong with the design, as long as it's carefully thought out, and implemented properly.

Some of the more common "problems" people associate with EAV are:

1. Good chance for poor performance
2. non-intuitive design leading to difficult application maintenance
3. virtually impossible to reliably enforce referential integrity

Good references abound:

1. https://softwareengineering.stackexchange.com/questions/93124/eav-is-it-really-bad-in-all-scenarios

2. Attribute and Value tables on SQL - Is this a good practice?

Porting a database from EAV structure to a more typical relational design will be very involved. Any and all code that touches the data will likely need to be changed. You could use triggers on the existing tables to allow you to slowly port code from the EAV model into a relational model, or possibly you could add a series of views over the re-modeled data to support reporting or other read-only aspects of the client application once you convert to a relational model.