Re: Modeling question...

From: Tim X <timx_at_nospam.dev.null>
Date: Sat, 26 Jul 2008 16:09:56 +1000
Message-ID: <87r69hp45n.fsf_at_lion.rapttech.com.au>


"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
> data

>> 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.

regards,

Tim

-- 
tcross (at) rapttech dot com dot au
Received on Sat Jul 26 2008 - 08:09:56 CEST

Original text of this message