Re: Dreaming About Redesigning SQL

andrewst <member14183_at_dbforums.com> wrote in message news:<3530842.1067342359_at_dbforums.com>...
> Originally posted by Mike Preece
> >
>
> > In both scenarios we have a many:many relation - but they're not
>
> > equivalent. Can you describe a scenario in which it would be equally
>
> > as important to get one part of a many:many relation as the other?
>
> >
>
> Yes, I agree that people and phones is not a "well balanced" example.
> Though it's worth pointing out that since the relational model avoids
> making such a value judgement, if it transpires that in the future we
> are very interested in a phone-centric view of the data, our database
> design is not biased against it.
>

Interesting way of putting it. The Pick model itself allows optimisation in the database design according to the importance placed on relationships between various data by the user - and is itself flexible enough to be easily adaptable to changing requirements, whereas the relational take on it is that it ain't exactly perfect but it's near as needs be and it'll be near as needs be forever more regardless of the requirements so long as the data stays essentially the same.

I think this might be an important point and one that is easily overlooked. Each requirement must be treated on its merits. If the requirements change in future then the system must be adaptable to those changing requirements. Downunder, where I'm from, there used to be a "She'll be right!" mentality - still is to a degree. If the tool wasn't quite right for the job, or a job wasn't done strictly according to requirements - near enough was good enough. "Who cares? if it gets the job done? Might not be spot on but near enough's good enough!". Is that the mentality we, as database "experts" should be adopting?

Mike. Received on Wed Oct 29 2003 - 07:23:23 CET