Re: Pizza Example

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:BR9hc.10111$576.2284_at_newssvr31.news.prodigy.com...
> "Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
> news:1a0hc.1963$GR.264088_at_attbi_s01...
> > The main difference between a Pick dbms query
> > optimization (PQO) and an RDBMS query optimization (RQO) is the PQO is
> > accomplished by the application developer and the RQO is accomplished by
> > pretty sophisticated RDBMS designer methodologies.
> >
> > The RQO is much more complex because it is designed to be a lot of
things
> to
> > a lot of people, while the PQO is much simpler because the application
> > developer usually knows the data access requirements (they designed
them)
> > and can incorporate optimization into the application.
>
> 1. That's more work the developer has to do
>
> 2. In a company of any size, and any level of turnover at all, that's just
> not true. No developer knows all of the data access requirements. And even
> with stable staff, they change, and a relational design will accomodate
that
> change better. Theoretically. :-)

Even in theory there are many kinds of oft-requested changes that are not handled better by the relational model. For example, the change in cardinality from 1 to many is a very common requested change. Someone puts an attribute in a base table for an e-mail address in the early 90's and they've lived with it so far but they really, really need to start recording as many e-mail addresses as the person gives them.

If this is a pick system, then you tell it that this is a multivalued field. There might be (but it isn't necessarily the case) a need to change input and output forms to allow for multiple values for that field as well. This is all FAR EASIER, both conceptually and in the details of making the change for Pick than for an RDBMS.

This is just one example of how, even in theory, it is not easier to maintain relationally-modeled data over time. --dawn Received on Tue Apr 20 2004 - 19:31:44 CEST