Here's a pointer to another database design question and response that comes up often in SO:
http://stackoverflow.com/questions/8609251/db-design-to-allow-user-to-define-products-product-specs-and-let-themself-inserThe first responder recommends E-A-V. The prevailing wisdom among today's database experts is that E-A-V is really, really cool. My own opinion is that E-A-V really, really sucks. It's an argument that I know that I'm not going to win. And it could just be a case where time has passed me by.
In any event, I've learned to just not answer this kind of question. What I don't want to be is the kind of participant that takes the same punches over and over again. I don't want to be a "Palooka".
http://www.politicsforum.org/images/flame_warriors/flame_46.phpLet me qualify my own opinion on this subject: E-A-V can work out really, really well, provided you never, ever, want to use data from different users integrated into a single coherent set of data. When you try to integrate the data, you find that the fact that each user can essentially design his own schema means that this data is not coherent at all. It's really a bunch of separate databases masquerading as a single one.
Perhaps my own opinion is biased by the fact that people like me get called in when some manager gets the bright idea to collect all that data in the database into a few simple management reports. That's when E-A-V comes back to bite you. And I had to learn to qualify my own thinking: I changed from "reports are easy" to "reports are easy, provided the data is coherent".
"Coherent" is one of those words that's "too philosophical" for many people in IT.
