Re: globals besides relvars?

From: Bob Badour <>
Date: Tue, 29 Jul 2003 11:31:31 -0400
Message-ID: <vrxVa.1418$>

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

Nobody is requiring an API. It's perfectly valid to raise the level of abstraction of your programming language to more closely integrate it with your dbms.

> > > > IMO A good catalog model would include relvars to holds things like
> > 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?

So that logic applies. I don't know how to say it any clearer. If you do not have it in a relation, you can no longer directly use predicate logic. You complicate things while making the system less functional. You can no longer manage your data with a simple relational language. You must manage your data with a more complicated language that has additional operations to deal with other structural elements.

> I've never heard a good reason to restrict ourselves in this way.

You have been given very good reasons recently. I suggest you contemplate those reasons a little more carefully before you conclude they are no good.

> > > I mean, the current timezone
> > > is not a relation, it's a value from the timezone domain. Current user
is a
> > > string or a User value or something. It's not a relation. So why must
it go
> > > into a relation? I'm already aware that Codd so asserted, but I don't
> > > see any good theoretical or even a good design reason for it.
> >
> > Good design: don't distinguish things unnecessarily.
> Also good design: don't force everything into a single model

That is not good design. That is unprincipled, arbitrary abdication of design. Design is meaningless without conceptual integrity. In the end, one still has a single model; except, it is a more complicated model.

> > Having *non-relation* variables makes the whole environment (much) more
complex, for
> > no benefit. Information is no longer democratic. Why should Timezone
get special
> > treatment and not, current bank balance or last update statement or
current query
> > optimisation level??
> Because there's only one value. Relations become pointless baggage for
> things that there's only one of.

Logic is pointless?!? Received on Tue Jul 29 2003 - 17:31:31 CEST

Original text of this message