Re: Relational and multivalue databases

"Dave Rolsky" <autarch_at_urth.org> wrote in message news:Pine.LNX.4.58.0402222336490.7194_at_urth.org...
> 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?

Sorry-- I should hvae defined my terms -- a mathematical function is a relation that has only one value for each element in the domain. I'm modeling the data in functions (which are then necessarily relations) and I use the word "functions" for two reasons: 1) because if I were to use the term "relations" then I would be corrected on the modeling into these relations because I do not use all of "relational database theory" and implementations of this "functional model" are not RDBMS's.
2) because I would rather work with functional databases than relational databases ;-)

>
> 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?

Oddly enough, having a database that does query optimization was not something I ever heard of until RDBMS's came about -- OF COURSE databases optimize the processing of the query -- that's one of their jobs, right? However, no matter how optimized queries are, stored data is faster to query than derived data.. Since the vocabulary for an entity is the combination of words for stored data and words for derived data, having a vocabularly element for the list of people who have this address, for example, is going to yield query results faster if the data is located there (in that same stored record) than if the data needs to be found and then derived from stored data in many other records..

> > 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.

definitely agree -- that is not the case.

> 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.

Each has its proc and cons, just as other models do. When I read books that talk about databases, they seem to indicate that relational databases are whats good and non-relational have somehow been proven to be the bad, old stuff. With OO, XML, and OLAP discussions added to some text books, this is starting to move a bit -- I'm just trying to help it move faster. Relational database are neither mathematically nor emperically proven to be superiour to anything, as best I can tell. They are simply one approach and not, in my opinion, the best that we, as an industry, can offer. smiles. --dawn Received on Mon Feb 23 2004 - 14:48:17 CET