Re: globals besides relvars?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Tue, 29 Jul 2003 10:31:20 +0100
Message-ID: <bg5f26$1946$>

"Marshall Spight" <> wrote in message


> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> > "Marshall Spight" <> wrote in message
> > news:S%bVa.149598$
> > > In many programming languages, functions have access to
> > > function-local state as well.
> >
> > So what? Programming languages have many things that we we don't need.
> > 'Functions' that access global data being just one of them.
> I don't agree.

> I think the entire model of the database as something that's
> "far away" from application logic, requiring an API for access, is part
> of what keeps databases from being as useful, and as pervasive, as
> they could be.

I do agree with that statement, but have no idea why that means you want persistence orthogonal to type.

> > > > IMO A good catalog model would include relvars to holds things like current
> > timestamp
> > > > and current USER.
> > >
> > > Okay, but why do these things have to be relvars?
> >
> > Because that's all we're got. Luckily, it's all we need as well. :-)
> The computing world has plenty of logical structures besides relations.
> We've also got lists, tuples, and individual non-relation values. Why
> can't we store them directly? Why do we have to wrap them in a relation?
> I've never heard a good reason to restrict ourselves in this way. I don't
> even see how it makes things any simpler; it makes them more complicated,
> because when you have a singleton value for something, you have to
> wrap it in a tuple and wrap that tuple in a set.

So you want Persistence orthogonal to type do you?

That is precisely what Date & Darwen argue against.

I'll refer you to their work, if you are in any doubts about why persistence should NOT be orthogonal to type.

The only things that are persistent are tuples in relations in the database.

Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Jul 29 2003 - 11:31:20 CEST

Original text of this message