Re: Generalised approach to storing address details
From: Cimode <cimode_at_hotmail.com>
Date: 7 Dec 2006 07:42:20 -0800
Message-ID: <1165506140.825365.275040_at_79g2000cws.googlegroups.com>
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/
Date: 7 Dec 2006 07:42:20 -0800
Message-ID: <1165506140.825365.275040_at_79g2000cws.googlegroups.com>
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 - 16:42:20 CET