Re: Dreaming About Redesigning SQL

Lee Fesperman wrote
> The OP needs to increase his knowledge of database concepts before he tries to 'fix'
> things. A newsgroup is the wrong place to get any real depth of understanding.

In that case, I would like to know what is the _right_ way to get the
depth of understanding. At the moment due to where I live I only have
access to internet resources, so what do you suggest? Besides, I find
that many people who have all followed the right way disagree on a
number of issues. I know that there are certain classic books that
would help (and I would like to be pointed to some more), but there
must be some web resources I've missed?

The observation is appreciated, a little assistance in this area would
be appreciated even more ;-). How else can I get in touch with very
smart people?

Seun Osewa

Thanks Jerry,

This seems a most reasonable, logical explanation for the current
state of things. And I guess it still explains why OO databases are
not catching on as fast as predicted today. The issue of flexibility,
the fact that the corporate database should be able to support several
generations of several Application programs ... and of course the
"critical mass" effect and the backing of major corporate players like
IBM must have done the rest.

Seun Osewa.

"Jerry Gitomer" wrote in message news:...
> The RDBMS wound up as the most popular approach to DBMS for practical
> business reasons. The premier DBMS at the time of the introduction of
> Oracle (the first RDBMS to hit the market) was IBM's IMS. IMS was much
> faster than Oracle and, given the concern about system performance in an
> era where supercomputers didn't have the performance of a Pentium, the
> fact that Oracle and subsequent RDBMS became more popular was due to the
> one factor which concerned businesses even more than bang for the buck.
>
> This was the cost of maintaining a working system. The primary advantage
> of the RDBMS over its predecessors in the 1970's was that the RDBMS was
> dynamic, while most of its predecessors were static. By that I mean that
> if the world changed it was easy to change the RDBMS model and code to
> meet the changing conditions. This was not the case with the
> alternatives.
>
> IMS was designed to optimize performance and, from what I recall, was very
> difficult to change. Even trivial changes in the real world could result
> in massive reprogramming efforts. Things were so bad that in some cases
> once the world started to change the programmers could barely keep pace
> and the use of a database became a liability rather than an asset.

Thanks Jerry,

This seems a most reasonable, logical explanation for the current
state of things. And I guess it still explains why OO databases are
not catching on as fast as predicted today. The issue of flexibility,
the fact that the corporate database should be able to support several
generations of several Application programs ... and of course the
"critical mass" effect and the backing of major corporate players like
IBM must have done the rest.

Seun Osewa.

"Jerry Gitomer" wrote in message news:...
> The RDBMS wound up as the most popular approach to DBMS for practical
> business reasons. The premier DBMS at the time of the introduction of
> Oracle (the first RDBMS to hit the market) was IBM's IMS. IMS was much
> faster than Oracle and, given the concern about system performance in an
> era where supercomputers didn't have the performance of a Pentium, the
> fact that Oracle and subsequent RDBMS became more popular was due to the
> one factor which concerned businesses even more than bang for the buck.
>
> This was the cost of maintaining a working system. The primary advantage
> of the RDBMS over its predecessors in the 1970's was that the RDBMS was
> dynamic, while most of its predecessors were static. By that I mean that
> if the world changed it was easy to change the RDBMS model and code to
> meet the changing conditions. This was not the case with the
> alternatives.
>
> IMS was designed to optimize performance and, from what I recall, was very
> difficult to change. Even trivial changes in the real world could result
> in massive reprogramming efforts. Things were so bad that in some cases
> once the world started to change the programmers could barely keep pace
> and the use of a database became a liability rather than an asset.

Thanks Jerry,

This seems a most reasonable, logical explanation for the current
state of things. And I guess it still explains why OO databases are
not catching on as fast as predicted today. The issue of flexibility,
the fact that the corporate database should be able to support several
generations of several Application programs ... and of course the
"critical mass" effect and the backing of major corporate players like
IBM must have done the rest.

Seun Osewa.

"Jerry Gitomer" wrote in message news:...
> The RDBMS wound up as the most popular approach to DBMS for practical
> business reasons. The premier DBMS at the time of the introduction of
> Oracle (the first RDBMS to hit the market) was IBM's IMS. IMS was much
> faster than Oracle and, given the concern about system performance in an
> era where supercomputers didn't have the performance of a Pentium, the
> fact that Oracle and subsequent RDBMS became more popular was due to the
> one factor which concerned businesses even more than bang for the buck.
>
> This was the cost of maintaining a working system. The primary advantage
> of the RDBMS over its predecessors in the 1970's was that the RDBMS was
> dynamic, while most of its predecessors were static. By that I mean that
> if the world changed it was easy to change the RDBMS model and code to
> meet the changing conditions. This was not the case with the
> alternatives.
>
> IMS was designed to optimize performance and, from what I recall, was very
> difficult to change. Even trivial changes in the real world could result
> in massive reprogramming efforts. Things were so bad that in some cases
> once the world started to change the programmers could barely keep pace
> and the use of a database became a liability rather than an asset.

Jan Hidders wrote in message news:...
> Seun Osewa wrote:
> > In other words do we have the model, the language, or standardisation
> > to blame/praise for the popularity of the relational model?
>
> Don't forget market domination.
By "standardisation" I really meant something close to market
domination.

> No. Procedural query language are a very big no no, because you should
> let the database choose how to optimize the queries and not let the
> users choose some optimizations on assumptions about how they think the
> data is stored.
If procedural languages are so bad for database access, how come all
the major database vendors (and now the SQL99 standard) have
procedural extensions? Procedural coding is flexible, powerful,
although not always the most elegant. There's a line we always have to
draw between what should be done procedurally and what should be done
declaratively because not everything can be done declaratively and you
have to depend on what is included in the database engine.

And personally I think that once you have identified the records you
are interested in, through a 'declarative' query which can be
optimized by the DBMS, one should be able to manipulate is with
relative freedom from a powerful-enough procedural. GROUP BY,
AGGREGATE FUNCTIONS, and any further processing or transformation of
the raw data are probably not so complicated that they cannot be
implemented as _libraries_ callable from the procedural language. And
yes, with such libraries the procedural code should be shortened.

So my developing idea is to have:
- A declarative language for indicating which data I am interested in.
- A procedural language for working on each record of the SELECTed
data: locking, unlocking, updating, creating data that depends on it
....

Does anybody on this list have information about "transactional"
languages or anything like that. A procedural language where all your
actions have no effect until you "commit" and you can rollback, etc?

Regards,
Seun Osewa
"There are things we do primarily because we think they are fun and
might just be useful to someone somewhere sometime ..."

Jan Hidders wrote in message news:...
> Seun Osewa wrote:
> > In other words do we have the model, the language, or standardisation
> > to blame/praise for the popularity of the relational model?
>
> Don't forget market domination.
By "standardisation" I really meant something close to market
domination.

> No. Procedural query language are a very big no no, because you should
> let the database choose how to optimize the queries and not let the
> users choose some optimizations on assumptions about how they think the
> data is stored.
If procedural languages are so bad for database access, how come all
the major database vendors (and now the SQL99 standard) have
procedural extensions? Procedural coding is flexible, powerful,
although not always the most elegant. There's a line we always have to
draw between what should be done procedurally and what should be done
declaratively because not everything can be done declaratively and you
have to depend on what is included in the database engine.

And personally I think that once you have identified the records you
are interested in, through a 'declarative' query which can be
optimized by the DBMS, one should be able to manipulate is with
relative freedom from a powerful-enough procedural. GROUP BY,
AGGREGATE FUNCTIONS, and any further processing or transformation of
the raw data are probably not so complicated that they cannot be
implemented as _libraries_ callable from the procedural language. And
yes, with such libraries the procedural code should be shortened.

So my developing idea is to have:
- A declarative language for indicating which data I am interested in.
- A procedural language for working on each record of the SELECTed
data: locking, unlocking, updating, creating data that depends on it
....

Does anybody on this list have information about "transactional"
languages or anything like that. A procedural language where all your
actions have no effect until you "commit" and you can rollback, etc?

Regards,
Seun Osewa
"There are things we do primarily because we think they are fun and
might just be useful to someone somewhere sometime ..."

Jan Hidders wrote in message news:...
> Seun Osewa wrote:
> > In other words do we have the model, the language, or standardisation
> > to blame/praise for the popularity of the relational model?
>
> Don't forget market domination.
By "standardisation" I really meant something close to market
domination.

> No. Procedural query language are a very big no no, because you should
> let the database choose how to optimize the queries and not let the
> users choose some optimizations on assumptions about how they think the
> data is stored.
If procedural languages are so bad for database access, how come all
the major database vendors (and now the SQL99 standard) have
procedural extensions? Procedural coding is flexible, powerful,
although not always the most elegant. There's a line we always have to
draw between what should be done procedurally and what should be done
declaratively because not everything can be done declaratively and you
have to depend on what is included in the database engine.

And personally I think that once you have identified the records you
are interested in, through a 'declarative' query which can be
optimized by the DBMS, one should be able to manipulate is with
relative freedom from a powerful-enough procedural. GROUP BY,
AGGREGATE FUNCTIONS, and any further processing or transformation of
the raw data are probably not so complicated that they cannot be
implemented as _libraries_ callable from the procedural language. And
yes, with such libraries the procedural code should be shortened.

So my developing idea is to have:
- A declarative language for indicating which data I am interested in.
- A procedural language for working on each record of the SELECTed
data: locking, unlocking, updating, creating data that depends on it
....

Does anybody on this list have information about "transactional"
languages or anything like that. A procedural language where all your
actions have no effect until you "commit" and you can rollback, etc?

Regards,
Seun Osewa
"There are things we do primarily because we think they are fun and
might just be useful to someone somewhere sometime ..."

Paul G. Brown wrote:
>
> Erm . .
>
> What's 'physical' about this?
>
> RELATION Dept ( Id Dept_Id KEY, Name String ); [....]

Absolutely nothing, of course, and just about any expert on database
theory (people who had several publications on PODS, ICDT, et cetera)
that I talked to about this agrees with you on this. In fact, I also
talked to some logicians (you know, people who actually know about what
is logical and what is not, :-)) about this question, and their answer
was that from their point of view it was in fact the String-part that
was less logical. This is not easy to explain in a few sentences but if
you are interested in the links between logic and the relational model I
can recommend you:

Jan Van den Bussche: Applications of Alfred Tarski's Ideas in
Database Theory. CSL 2001: 20-37

It's on-line at:

http://citeseer.nj.nec.com/vandenbus...lications.html

Especially important is the reference

[59] A. Tarski, "What are logical notions?", History and Philosophy
of Logic, 7:143-154, 1986, Edited by J. Corcoran.

but unfortunately I couldn't find that on-line. To get an idea read the
definitions at the end of page 2 and beginning of page 3 in the paper by
Van den Bussche. It's not easy stuff if you're not used to it, but I
hope you will understand that what it says there is that logical notions
treat the atomic values as *abstract* values, which is what references,
object identifiers, logical pointers or whatever you want to call them,
actually are. And Alfred Tarski, who may be considered as one of the
founders of modern logic, consideres this to be such a fundamental
property of logical notions that he in fact uses it as the very
definition of what a logical notion is.

So am I arguing that we should only use abstract values in the columns
of our relations? Certainly not. What Tarski presents here is a
simplified model that he uses to understand certain properties of
logical systems. But what this does tell you is that from a logical
point of view there is no problem with abstract values and in some sense
they can even be regarded as more fundamental than concrete values.

-- Jan Hidders

Paul G. Brown wrote:
>
> Erm . .
>
> What's 'physical' about this?
>
> RELATION Dept ( Id Dept_Id KEY, Name String ); [....]

Absolutely nothing, of course, and just about any expert on database
theory (people who had several publications on PODS, ICDT, et cetera)
that I talked to about this agrees with you on this. In fact, I also
talked to some logicians (you know, people who actually know about what
is logical and what is not, :-)) about this question, and their answer
was that from their point of view it was in fact the String-part that
was less logical. This is not easy to explain in a few sentences but if
you are interested in the links between logic and the relational model I
can recommend you:

Jan Van den Bussche: Applications of Alfred Tarski's Ideas in
Database Theory. CSL 2001: 20-37

It's on-line at:

http://citeseer.nj.nec.com/vandenbus...lications.html

Especially important is the reference

[59] A. Tarski, "What are logical notions?", History and Philosophy
of Logic, 7:143-154, 1986, Edited by J. Corcoran.

but unfortunately I couldn't find that on-line. To get an idea read the
definitions at the end of page 2 and beginning of page 3 in the paper by
Van den Bussche. It's not easy stuff if you're not used to it, but I
hope you will understand that what it says there is that logical notions
treat the atomic values as *abstract* values, which is what references,
object identifiers, logical pointers or whatever you want to call them,
actually are. And Alfred Tarski, who may be considered as one of the
founders of modern logic, consideres this to be such a fundamental
property of logical notions that he in fact uses it as the very
definition of what a logical notion is.

So am I arguing that we should only use abstract values in the columns
of our relations? Certainly not. What Tarski presents here is a
simplified model that he uses to understand certain properties of
logical systems. But what this does tell you is that from a logical
point of view there is no problem with abstract values and in some sense
they can even be regarded as more fundamental than concrete values.

-- Jan Hidders