Re: Dreaming About Redesigning SQL

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<zYidnSyGvvXi6zmiRVn-sw_at_golden.net>...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:h%Qob.56961$mZ5.338904_at_attbi_s54...
> > "Mike Preece" <michael_at_preece.net> wrote in message
> news:1b0b566c.0310312141.67b3f186_at_posting.google.com...
> > > If it becomes necessary to record more than one phone number against a
> > > person, does the relational model dictate that the logical schema must
> > > change?
> > Yes. Doesn't the Pick model as well?
> Yes and no. Pick will never prevent a user from entering multiple values
> where the designer anticipates a single value. In this sense, one does not
> need to tell Pick anything different to accept multiple values. However,
> when the user enters multiple values, the user will implicitly change the
> meaning of all existing queries that anticipate a single value, and in this
> sense the Pick logical data model requires the logic to change as well.

I'm not sure what point you're trying to make here. Perhaps it would help if you could provide an example illustrating the logic that would need to change if we change from only ever storing a single unique phone number to storing multiple, possibly shared, phone numbers.

> > Isn't the size constraint on the
> > number of phone numbers part of the schema?
> Not in Pick. It lacks integrity.

C'mon Bob. Don't be so lazy. You mean, I think, that Pick doesn't have centrally enforced integrity constraints as part of the file system. In this you are correct. That does not mean they can't be enforced in the DBMS. This has been thrashed out in other parts of this and other threads. Look: if a Pick DBMS is abused data integrity will be a problem, I admit it - it must be enforced. I would ask you to consider though, that there are millions of Pick systems out there - many of them in your government and financial institutions. Please believe me - data integrity is vitally important to them. I leave you to make up your own minds as to where the integrity rightfully belongs.

> > > This doesn't have to happen in Pick. An attribute can be multivalued.
> > Are you considering an attribute changing from single-valued to multivalued
> > as NOT being a schema change? Or does Pick not have a way to distinguish
> > between the two cases?
> The way Pick will interpret queries changes when the data becomes
> multivalued, but Pick makes no particular distinction in the schema. For
> some reason, Pickies think not knowing how the product will interpret the
> data is an advantage. As I have repeated many times, these individuals are
> ignorant and stupid.

I really think an example might help us understand what you mean. Perhaps we can help you and others in "knowing how the product will interpret the data". It would be good if you could keep to the PersonsPhones theme.

Prove to us that, although you do often slip into the "...ignorant and stupid" stuff, you really are worth discussing this with. Received on Sun Nov 02 2003 - 09:32:12 CET