Re: globals besides relvars?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:XbmVa.5101$It4.2779_at_rwcrnsc51.ops.asp.att.net... > "Bob Badour" <bbadour_at_golden.net> wrote in message news:dkfVa.1371$%e2.247791731_at_mantis.golden.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:WqcVa.148132$GL4.38052_at_rwcrnsc53...
> > > > No 'function' requires global state information.
> > >
> > > What about functions that have access to the database?
> >
> > A function has access to its parameters. No function needs access to the
> > database except as a parameter.

>
> Some code somewhere needs to access the database. Application code
> needs to access the database. If there isn't some way for code to access
> the database, then the database is useless.

What part of 'except as a parameter' escaped you?

> > Everything ultimately accesses global state information. The question
is:
> > Does it access it explicitly as global state information or does it
access
> > the state information as an argument to a well-defined parameter.
>
> Where did the calling code get access to the well-defined parameter?

From an external actor.

> > > > Your problem is imagining that this simple datum is a function.
> > >
> > > And why is it not a function?
> >
> > It is a simple datum. Why is it a function? A function of what?

>
> Every simple datum is also a well-formed function: the function
> of zero inputs and the datum as output.

Not every value defines a singleton type.

> > > For example, I'd rather invoke the getTimeZone() function
> > > than:
> > >
> > > Select * from TimeZone
> > > unwrap relation into tuple
> > > unwrap tuple into value
> >
> > What makes you think that one would have a TimeZone relvar? TimeZone is
> > simply an attribute of a relvar, and I fail to see why one would need to
> > unwrap it to use it.
>
> Even TTM admits to the necessity of having these unwrap operators.

"One can" and "one must" are very different things; perhaps, you would understand things better if you addressed the examples I give instead of cutting them out.

There was no unwrap in:

EXTEND ( CurrentUser{ Name, TimeZone } JOIN System{ Now } ) ADD String ( Now, TimeZone ) AS LocalNow

What makes you think that one would have a TimeZone relvar? It's nonsense.

> > > There's nothing about the word "store" than mandates an
> > > implementation meaning. I can logically store some information just
> > > as well as I can store it on a disk sector.
> >
> > After you explain to me how you can speak about storing something
without
> > any reference to a storage location, I'll reconsider my opinion.
>
> "Joe, here's a bunch of information about our users and what timezones they
> are in. Could you store it in the database, please? Use the timezone table."

Joe physically stores the data in the database. Your statement includes the physical location.

> > Until then, I will continue to reserve storing for
> > the physical and representing for the logical.

>
> Well, now we each know what the other thinks the word "store" means.
> I note that searching Google for "stored in {a|the} {file|database}"

> more hits for the database use of the word than the file use of the word,
> so I think common usage, at least, is against you. (Not that common usage
> is definitive.)

Implemented databases are both logical and physical. Why should it surprise me to find people using 'to store' to describe physical operations on databases?

You started this thread by claiming you do not understand the relational requirement that the dbms only represent variable data using relvars. The difference between logical and physical cuts right to the heart of the matter.

The relational model imposes no restrictions on how a dbms stores data; it only restricts how the dbms logically represents the data it stores.

> > > Don't functions have access to the database?
> >
> > Why should they have access to anything except their parameters?

>
> Because the database is just full of useful information. Functions
> which have access to this information will be able to do more useful
> things than functions which don't have access to it.

Let's presuppose a function that sees a global database variable as part of its scope. The scope of the function is necessarily a superset of the scope of the database. Can we agree that any function with unparameterized access to a global database variable is external to the database variable? If it is not external, in what way is it not external?

> > > I'm groping my way towards a model where the concept of a
> > > programming language's global variables and the concept of
> > > the database are merged. They perform the same function; no
> > > need to have both concepts. Clearly the database world has
> > > the better notion of global state anyway.
> >
> > I suggest that they perform different functions. For instance, an
> > application's global variables generally do not persist across
executions of
> > the application. There are strong arguments for severely restricting the
use
> > of global variables in application programming languages, and equally
strong
> > arguments for maximizing the use of global variables in database
management
> > systems.

>
> Well, yeah, that's how everyone thinks about it now. I think that makes database
> access unnecessarily complicated, though.

If database access is already too complicated, why do you want to complicate it further by introducing additional structural elements?

> Why do we need a separate model
> for global data in applications, and persistent data in applications?

We don't need a separate model. We can raise the level of abstraction of our programming languages to use relation variables directly.

> I note
> that databases often support temp tables.

Language constructs like 'WITH' in D that allow one to use locally scoped names for relational expressions are useful aids to comprehension. Systems like sybase and sql-server that require the use of temporary tables to overcome fundamental flaws in the optimizer are less desirable. Received on Tue Jul 29 2003 - 19:01:17 CEST