Re: ID field as logical address

On Jun 2, 10:26 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> David BL wrote:
> > On May 31, 10:20 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
> >> one of the many other confusions I snipped is that assignment is part of
> >> relational theory, whereas it's not, it is a concept certain kinds of
> >> languages need.
>
> > If by "relational theory" you mean the relational algebra then it's
> > true it doesn't include assignment. But obviously the sub-topic
> > concerns the changes to a relational /database/ over time.
>
> > This news group by definition concerns database theory. The main
> > purpose of a database is to record values in variables. Whenever a
> > variable is changed it has by definition been assigned with a
> > different value.
>
> > I doubt you'll take my word for, but perhaps you'll listen to Bob. The
> > following quote comes from a post by Bob in Oct 2003:
>
> > All D's are imperative. Imperative languages comprise
> > those languages that operate by changing the state of
> > variables. Since a database is a variable, imperative
> > languages are entirely appropriate for data management.
> > Regardless whether one writes expressions using the
> > calculus or the algebra, one manages the data by
> > changing the state of the database variable.
>
> If you're trying to say RT allows languages that support pointers, okay.
> If you're trying to say RT requires an imperative style, eg.,
> languages that support pointers, you're wrong.

Any instruction to update the database state is imperative by definition. What else do you think imperative means?

[snip]

> Just because db values vary
> doesn't mean one must implement variables and assignment.

Values don't vary by definition. Only variables can vary.

How can you accuse folks of being confused when you don't even appear to have grasped the most basic definitions?

[snip] Received on Wed Jun 03 2009 - 03:16:59 CEST