Re: Relational and multivalue databases

On Sun, 22 Feb 2004, Dawn M. Wolthuis wrote:

> Yes, Marshall, you are right that I answered the specific instance and not a
> generalization. When it comes to addresses, they are many-to-many with
> people, while 1-1 with places (if we can make the assumption that each place
> has one and only one address). I know the language I'm about to use doesn't
> play well with the RDBMS theorists, but I would think of my entities as
> people, places, and things. Addresses go with a "Places" entity, perhaps
> named "Addresses".
>
> So, we have people and we have addresses with a M-M relationship. In a PICK
> model, the implementation would likely include a PEOPLE function and an
> ADDRESSES function (called "files"). The PEOPLE function would map to a
> list of ADDRESSES identifiers. Two files with a link between them.
>
> Often the implementation would include return-links to improve performance
> if there would be queries not just about what addresses a person has, but
> also who lives at a particular address. Then extensions could be made to
> the vocabulary of each function so that queries like this would be the norm:
>
> LIST PEOPLE FULL-ADDRESSES
>
> LIST ADDRESSES FULL-NAMES
So basically what you're saying is you'd write custom code (if I read the word "function correctly" here) to do what a relational database would you let you do with it's query language?

And you'd do that _every_ time you had to express an M-M relationship?

And if you _don't_ implement these performance improving return links, the database cannot optimize that query?

> This approach is much more like the web, where there are documents with
> links to other documents, which might then have return links to all docs
> that point to them. Part of the charm is in the simplicity of the approach.

I don't see the charm in having to hand-code the same thing over and over again.

I'd rather declaratively say "this is my data, these are the relationships between them", and have the DBMS take care of the optimization.

Granted, today's SQL databases don't handle this perfectly, but they're not all that bad at it either.

-dave

/*=======================

=======================*/