Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm thinking to use EAV for some of the stuff in one of the projects, but all questions about it in stackoverflow end up to answers calling EAV an antipattern.
But I'm wondering, if is it that wrong in all cases?
Let's say shop product entity, it has common features, like name, description, image, price, etc., that take part in logic many places and has (semi)unique features, like watch and beach ball would be described by completely different aspects. So I think EAV would fit for storing those (semi)unique features?
All this is assuming, that for showing product list, it is enough info in product table (that means no EAV is involved) and just when showing one product/comparing up to 5 products/etc. data saved using EAV is used.
I've seen such approach in Magento commerce and it is quite popular, so may be there are cases, when EAV is reasonable?

share|improve this question
    
all answers are good, so +1 to all and longest marked as an answer –  Giedrius Jul 18 '11 at 7:26
add comment

3 Answers

up vote 12 down vote accepted

This is a good forum discussion on this very topic and good points are brought up on both sides of the argument.

http://www.dbforums.com/database-concepts-design/1619660-otlt-eav-design-why-do-people-hate.html

EAV gives a flexibility to the developer to define the schema as needed and this is good in some circumstances.

On the other hand it performs very poorly in the case of an ill-defined query and can support other bad practices.

In other words, EAV gives you enough rope to hang yourself and in this industry, things should be designed to the lowest level of complexity because the guy replacing you on the project will likely be an idiot.

share|improve this answer
add comment

In a nutshell, EAV is useful when your list of attributes is frequently growing, or when it's so large that most rows would be filled with mostly NULLs if you made every attribute a column. It becomes an anti-pattern when used outside of that context.

share|improve this answer
add comment

Typically people look the other way if you're using it for lookup tables, or other situations where the benefit is to keep from having to create tables for one or two stored values. The situation you're describing, where you're basically storing item properties, sounds perfectly normal (and normalized). Widening a table to store a variable number of item attributes is a bad idea.

For the general case of storing disparate data in a long thin table...You shouldn't be afraid to create new tables if you need to, and having just one or two long skinny tables isn't much better than having only one or two short fat tables.

That being said, I am notorious for using EAV tables for logging. They do have some good utility.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.