EAV is a non-relational design and trying to make it fit in an SQL database is a fool’s errand.

By using EAV, you’ve already sacrificed any benefit using an RDBMS might have given you, so why are you still using an RDBMS?

If EAV really seems like what you need, you should use something like CouchDB, Apache Cassandra , Project Voldemort, or one of the other emerging key/value storage technology.

I don’t mean to be cranky, but this is really one of those square-peg-in-a-round-hole situations.

Arnold replied: “The issue with document oriented databases is that it is very difficult to get results based on referential info.”

Yes, but neither can you support referential integrity constraints in EAV. A constraint on a column applies to all rows, not just some rows, where the fid is a certain value.

Arnold: “I would not be a good idea to make a table with millions of fields or make a db with a table for each illness.”

Yes, the seminal use of the EAV data model is in medical databases in the 1970’s, where a patient entity has thousands of boolean attributes, forming a sparse matrix of the illnesses and conditions that apply. So EAV was used so that the attributes could be stored as rows, instead of columns, because a table with thousands of columns was impractical.

But the relational model for patients-to-conditions is simply a many-to-many relationship. Yes, we can store rows to represent the boolean association from a patient to a given condition. And we can store the possible conditions in rows too–in a lookup table also referenced by the many-to-many intersection table.

CREATE TABLE HasCondition (
patient_id INT REFERENCES Patients,
condition_id INT REFERENCES Conditions,
PRIMARY KEY (patient_id, condition_id)
);

Arnold: “Wanting to make the DB more flexible is not a valid reason to choose EAV.”

This I agree with. There are several ways to solve that problem, while keeping the separation between data and metadata. These solutions therefore support other core relational features such as typing and referential integrity, without employing the “Inner Platform Effect” antipattern.

If you really, *REALLY* need to support custom user-defined attributes, I’d recommend the “Serialized LOB” approach, encoding the custom attributes in XML or JSON or whatever, and stuffing them into a blob. You aren’t sacrificing any query power, because you’ve already given that up as soon as you consider EAV.

Thanks
Ivan

A correctly functioning EAV database management system has to be built from the ground up.

Check out http://www.lazysoft.com and the Sentences database

Sentences provides the architecture, the schema, data, form and query tools you need to create an EAV database that is powerful, scalable, distributable.

Relational databases are based on lattices not the scalable networks of EAV.

Our application offers users the ability to create user defined fields. We have one client who has created 150+!!

The way I originally tackled this was via a simple EAV mechanism like this:

table UDF_DEFINITION
id (integer) PK
caption (varchar)
datatype (varchar) constrained by domain to presets such as ‘Text’, ‘Date’, ‘Number’ etc.

table UDF_VALUE
id (integer) PK
id_udfdefinition (integer) FK to UDF_DEFINITION table
id_client (integer) FK to CLIENT table
data (varchar) i.e. value

So I could do something like this:

SELECT uv.* FROM udf_value uv JOIN client c on c.id = uv.id_client

This model was OK when we were returning ALL the data into a grid. However, it started to fall apart at the seams when we were asked to return paged search results based on search criteria.

The problem here as Antonin says is with sorting and paging. The problems were 2 fold:

1) Having my udf data all as VARCHAR meant that it is a pain in the *ass to order the data without having the correct data type.

2) Because you cannot apply a sort until you’ve returned the whole results set due to the pivoted nature of the data. So this becomes a cross tab like performance hog on searches. A no no.

I have rejected altering the schema on the fly because it seems inherently dangerous when you have multiple users connecting concurrently. Also if I have to create a table for each UDF then I’ll end up with 150+ joins in my SQL! Also, for me it’s risky. In my experience, if it can go wrong, it WILL go wrong.

I have rejected using a non RDBMS storage type as all the rest of the app works off flat tables. So I refuse to go to that level of complexity for one feature.

i am now leaning towards distributing the data into separate columns. The possibilities I see are:

1) I then i can return the whole row and pick off my values in code using a switch by parsing the type for that definition id.
2) I can keep a read only data varchar value updated via triggers so that i can still do a search on a plain text field. (I havent thought this one through fully so it may not work)

Any comments or assistance welcome.

It’s true it looks somewhat like the OTLT pattern, however it does not have most of the described drawbacks.

http://decipherinfosys.wordpress.com/2007/02/01/otlt-one-true-lookup-table

b.) Numeric values are saved as numbers and not as strings.
c.) Strings are saved in a variable sized column. The index makes sure it’s fairly searchable.
a.) Values are only joined to one table `field_option`.
d.) Values are only joined using INTEGERS.

It’s true though that you have to write complex and relatively slow queries to filter using the EAV table.

The issue I have with the articles condemning these structures, is that they are comparing very simple DB schemas with EAV. In that case there is no reason to use EAV. This structure is useful when the alternative is using either hundreds of tables or thousands of fields. Wanting to make the DB more flexible is not a valid reason to choose EAV.

http://www.google.com/search?q=otlt

First of all thanks for commenting on my blog and participating in what has become a bit of a discussion.

Using the result of a function in a WHERE condition with a substantial amount of records, will surely be slow. I don’t think anyone will dispute that. However, I have not found any situation where I need to cast a field on-the-fly. If you do have a situation like that, this method will not work well.

I only need to do select based on integers, which is quite fast. Converting the filter values into integers before putting them into an SQL statement is is not dependant of the amount of records and is unlikely to make any performance hit.

Could you please give an example where you need to cast on-the-fly in a WHERE statement?

I try to free up some time to benchmark the 3 approaches in order to give a conclusion.