Frank Millman a écrit :
EAV were once quoted on dbdebunk..I like this one...
I have done an Entity-Attribute-Value database design before. The big
advantage is that much of your logical model is stored as data rather
than as schema, so changes to the logical model can be made without
changing the schema. And if you write your sprocs correctly, you won't
need to change them either. The drawback? VERY complicated SQL code.
The main reason I used this was for a client that did not have a clear
understanding of their own requirements, but needed a working
application on a deadline. The EAV schema allowed me to deal with
constantly redefined business rules and requirements. Phase two of the
project would flatten out the schema, assuming most of the discovery
was accomplished in phase 1. I would not shirk from using EAV again,
but project managers balk at it because the cannot understand the
concept or the read the SQL code to support it. This always ticks me
off, because it's like a project manager telling a developer to code in
BASIC using GOTO statements because that is all he can understand
--blindman, sqlteam.com/forums/
Hope this gives an idea about EAV...
Received on Thu Dec 07 2006 - 09:42:20 CST
