Re: Dreaming About Redesigning SQL

Originally posted by Marshall Spight

> "Mike Preece" <michael_at_preece.net> wrote in message news:1b0b56-
> 6c.0310240611.1b130a87_at_posting.google.com"]news:1b0b566c.0310240611.1-
> b130a87_at_posting.google.com[/url]...

> > On the contrary. Enforcing integrity is, in the experience
> of

> > SQL-relational database adherents, of crucial importance. It is
> not

> > important to the same degree in Pick.

>

> I think what you mean to say is that it's not as hard. I don't think

> you mean to say that data integrity is not important for Pick.

> Do you? You're not saying that data corruption is okay, right?

>

>

> > This is because there are fewer

> > tables and fewer pointers between those tables - hence, less
> critical

> > need to maintain their integrity. Where a SQL-relational
> database has

> > pointers to tables containing related data, ...

>

> (Don't say pointers! Foreign keys are not pointers, even if they

> look like them.)

>

>

> > ... Pick has the data within

> > the same item. Pick is a more sophisticated model resulting in
> simpler

> > databases.

>

> Um, can I ask a question? How do you handle what the RDBMS guys

> call a "many-to-many" relationship? That is, let's say we have people

> and phone numbers, and a single person may have arbitrarily many

> phone numbers, and a single phone number may be shared by

> arbitrarily many people. For example, I have a land line at my

> house that's associated with me, my wife, and my two kids. I

> also have a cell phone that's associated just with me, and my

> wife also has a cell phone. And I have a work phone: just for

> me. My wife and I share a fax number, too. There's also a

> main switchboard number at work that you can use to reach

> me, but also everyone in my building. Get it?

>

> How can you have "the data within the same item" when

> there's no way to pick one vs. the other?

>

>

> Marshall

Sure you can ask questions. I might well ask some of my own. It's one of the reasons for participating right?

I guess I should start the reply by saying yes, we *can* have "the data within the same item" - but we don't have to. Just because we have multi- and sub- values available to us doesn't mean we have to use them. Therefore, any data structure you care to come up with for an SQL-relational database could be applied in the exact same form on a Pick database.

 In your example, we could have:

File: People

ID: PersonalID

001: Phone Numbers (multivalued)

..and any other data relating primarily to the person

and:

File Phones

ID: Phone Number

001: Phone type ('C'ell, 'H'ome, 'F'ax, 'W'ork, 'D'irect or whatever)

002: PersonalIDs (multivalued)

..and any other data relating primarily to the phone

or we could have:

File: People

ID: PersonalID

001: Location codes (multivalued)

..etc

and:

File: Locations

ID: Location code

001: PersonalIDs (multivalued)

002: Phone numbers (multivalued)

..etc

and:

File: Phones

ID: Phone Number

001: Location codes (multivalued)

..etc

or we could have:

any other data structure you want to have...

N.B.: We *can* use multi- and sub- values in Pick. We don't *have to*.

Also N.B.: The PersonalID, Phone Number and Location codes above are *actual keys*. The DBMS does a direct hashed read based on the 'ID' to get the information to and from disk quickly.

Mike.

--
Posted via http://dbforums.com