Re: Modeling question...
Date: Sat, 26 Jul 2008 16:09:56 +1000
"David Cressey" <cressey73_at_verizon.net> writes:
> "Volker Hetzer" <firstname.lastname_at_ieee.org> wrote in message > news:g6cmjq$9s9$1_at_nntp.fujitsu-siemens.com...
>> Bob Badour schrieb:
>> >>> Ooooh! Reinventing EAV with levels...
>> >> Possibly. I had a look at
>> >> http://ycmi.med.yale.edu/nadkarni/eav_CR_contents.htm and didn't find
>> >> anything exciting.
>> >> All my attributes (key value pairs) are (for the purpose of this
>> >> discussion) strings, so the Data tables hierarchy ends with
>> >> EAV_Objects in the first image of that link.
>> >> My problem is that, that I haveTest three different "Objects_1"
>> >> tables and I'd like to avoid having to replicate the EAV_Objects-Table
>> >> for each "Objects_1"-Table.
>> >> OTOH, I could have the "level" entities all be children of an id table
>> >> and
>> >> put the key value pairs into a child of that table. I need to try this
>> >> out.
>> >> Thanks for providing the pointer!
>> >> Volker
>> > Just to be clear, I was more than offering a pointer. I was also
>> > ridiculing the idea of EAV.
>> I got that. :-)
>> But "we want to be able to create and delete attributes" is a customer
>> requirement. I think it's different from "I am too lazy to do a proper
>> model". There are plenty of "normal" attributes left to model ERD like.
>> > > Here's the problem with the customer requirement that "we want to be able to > create and delete attributes": the same customers nearly always want to be > able to derive value from the data in the database by using it with standard > queries to drive standard reports, charts, or extracts that can be fed to > another process. After all, that's inherent in database data, isn't it? > Well, not if the customers can each invent their own attributes, it isn't! > > If you've never been down this road before I suggest you stay in the same > job long enough to see what happens when you tell the customers that each of > them has to design their own queries, because each of them defined their own > attributes. What happens isn't pretty!
I would have to agree very strongly here with David's warning. I also suspect that the customer's 'requirements' may actually represent a misunderstanding on their part or at least poorly expressed requirements. I would strongly recommend digging deeper and finding out more about why they feel this requirement is necessary. It reminds me of many clients I have had who bring me a solution to implement rather than bringing me the requirements and letting me come up with a solution in conjunction with them. This is a frequent and difficult problem faced by developers. You need to dig deeper and understand why they believe they need the ability to add/drop attributes.
-- tcross (at) rapttech dot com dot auReceived on Sat Jul 26 2008 - 01:09:56 CDT