Just a little further to this. Isn't minimising the number of joins required for retrieval like I'm doing going to improve the performance... or is the gain negligible?
Gareth. > -----Original Message----- > From: Eddie Bush [mailto:[EMAIL PROTECTED]] > Sent: Friday, 13 September 2002 4:58 a.m. > To: OJB Users List > Subject: Re: AW: Thankyou and nested attributes again > > > Thomas Mahler wrote: > > > Hi, > > > > Eddie Bush wrote: > > > >> Mahler Thomas wrote: > >> > >>>> Oh... and why don't we use a 1:1 reference to a separate > Quantity > >>>> table? > >>>> Because no matter how hard I try, I can't convince > people that we > >>>> shouldn't > >>>> let customers use Crystal Reports to report directly from the > >>>> back-end. So > >>>> in the interest of not confusing customers too much, the > >>>> denormalisation is > >>>> necessary. > >>> > >>> Cool argument! > >>> I propose to push this concept one step further: > >>> why not have a totally denormalized database with only one table? > >>> This will allow Excel users to understand your system :-) > >> > >> Couldn't you provide the same functionality with a view > (rendered by > >> a stored procedure, perhaps) -- and thereby preserve > normalization in > >> the actual tables? > > > > My proposal was a joke! please don't apply it to real systems! > > > > cheers, > > Thomas > > I know that! LOL - I'm not *completely* stupid ;-) I was > saying though > that, since Gareth felt the need to de-normalize things for > customers' > use, he could, rather than actually denormalizing his entire DB, just > build denormalized views. That way, he could retain normalization in > his "proper" tables. > > Regards, > > Eddie > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
