Re: Modelling objects with variable number of properties in an RDBMS

FrankHamersley wrote:
> VC wrote:
> > "Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message
> > news:YHY9f.4683$Rl1.3852_at_newsread1.news.pas.earthlink.net...
> >
> >>VC wrote:
> >>
> >>>"Roy Hann" <specially_at_processed.almost.meat> wrote in message
> >>>news:9v-dnYE-SanY6PreRVnygg_at_pipex.net...
> >>>
> >>>>"vc" <boston103_at_hotmail.com> wrote in message
> >>>>news:1130765800.098046.93870_at_f14g2000cwb.googlegroups.com...
> >>>>
> >>>>>Roy Hann wrote:
> >>>>>....
> >>>>>
> >>>>>>Actually no, let's not. What you have re-invented here is the tired
> >>>>>>old
> >>>>>>entity-attribute-value (EAV) design (much beloved of medical research
> >>>>>>wonks for some reason).
> >>>>>
> >>>>>Often they do that (EAV) not because they do not know any better but in
> >>>>>order to overcome a specific database physical limitations. Their
> >>>>>entities very often contain thousands of attributes (molecular
> >>>>>biology/pharmaceutical research/drug discovery) [snip].
> >>>>
> >>>>Always check the bath water for babies...
> >>>
> >>>I beg your pardon ?
> >>
> >>There's an old saying "Don't throw the baby out with the bath water".
> >>In this context, it means (roughly) make sure you don't lose the benefits
> >>of the relational model by thowing away all the rules that help
> >
> > I know that, but what recipe does Roy suggest for, let's say, MS SQL Server
> > that does not have either UDTs or other means to implement an entity with a
> > higher than the table limit number of attributes, beyond offering a cute
> > saying ?

>

I am not affiliated with the shop in question. The designer who suggested EAV did not have a choice in the matter. SQL Server was a constraint.

>

See above.

>
> Cheers, Frank.
Received on Wed Nov 02 2005 - 07:51:42 CST