Re: Windows Ada database support.

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 30 Nov 2004 16:07:06 +0000 (UTC), Georg Bauhaus wrote:
: 
:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>: On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote:
:>:>:>   See also Frank Piron's comment about implicit cursors in
:>:>:> PL/SQL.
:>:> 
:>:> Wrong abstractions in PL/SQL too?
:>: 
:>: Is in your opinion PL/SQL better than Ada?
:> 
:> PL/SQL has a specific purpose, and a rich set of facilities for handling
:> relations.
: 
: 1. Why relations should be handled?
: 2. Why Ada cannot handle them?

One reaon that Ada, as is, cannot handle the same set of problems
as PL/SQL with the same ease is, I think, that PL/SQL is a programming
language with built in support for database operations. You'd have to
define at least everything that has been defined (or not) for PL/SQL,
taking into account all Ada features and requirements.



:> I don't see why anyone using an Oracle DB would want to write
:> stored procedures in Ada?
: 
: Fair enough. Compare: "I don't see why anybody using C would want to switch
: to Ada". Indeed, they don't.
 
Some do switch from C to Ada, because Ada solves a problem.
If the task at hand is to write a conditionally triggered
procedure that processes a value before it is inserted into
a table, and hides this fact away from a client, that's fairly
easy in PL/SQL. It's just not there in Ada, AFAIKT.
  What is your estimate of the effort it takes to merge this
into Ada packages at a nice level of abstraction? For comparison,
have a look at APQ, then at GNADE.

 
: You could simply say: we need no generic data base interface.
 
In fact we have convenience objects, but still it is necessary that we
can get through to the database.

 
: So the point is: "real-time constraints cannot be met if data structures
: are extensible"?

If real-time constraints cannot be met using a DB system storing
more fancy data structures, I have to look for an alternative
solution. The opposite direction away from RDBs seems to be a big problem;
as has been mentioned, we have some object-relational DBs, 
some more advance O-O DBs, and some DBs that can store XML-like
documents.

Have a look at Microsoft's WinFS plans. Consider how long it takes
for the biggest and richest software company to come up with something
working. Substract compatibility issues and the profit made by selling
interim improvements. Is it easy to build something that covers
more than RDBMSs do?


:> And they do not always match the types of application data, which
:> can be of a rather fixed shape.
 
: Why?

There are things whose property set doesn't change frequently ;-)

: From my experience, there was no single case, when our customer didn't
: ask for an extensible data model [and was told that he/she cannot afford
: it]. Sooner or later they will break the wall.

Yes, sounds familiar, but first, hitting the wall is not equal to ruin
as the technicians like to think ;-) and second, you'd have to demonstrate
that an extended data model can be realized by just extending types.
It might be necessary to add or change change types and add or change
relations between types etc.


:>: The same way we program concurrent distributed applications in Ada!
:> 
:> And you know what people say about task switching? Rendevous has
:> its temporal aspects, how do you abstract them away?
: 
: I wouldn't. But it is perfectly possible. In C, which has no tasks, an
: entry is replaced by a procedure with an additional parameter TimeOut.

So adding a TimeOut parameter is an abstraction of a task entry?

 
: Basically I am unable to see any crucial difference between a data base
: engine or embedded controller or JVM. Tell me
: 
: 1. Why Ada cannot be targeted there?

Who said so?

: 2. Why Ada will be less efficient than SQL?

Again, Ada /= SQL, see above. Efficiency here is not necessarily
a matter of PLs, but of how an operation can be performed regardless
of implementation language at either end of the communication. If
the program is blocking resources due to generalized expectations
about cursors in some nice DB abstraction there is an efficiency
problem.

 
: They will invest in other things. Nowadays, nobody invests in chopping
: firewood...

Well, some do. (I've had to find firewood and briquettes for some 10 years,
so I know. And those who have nice firesides in their homes need it, too.)

 
:>:> What has Ada versus Assembly got to do with resource consumption of
:>:> communicating programs (Ada program <-> database program?)
:>: 
:>: It is because you present performance as an argument for using a low level
:>: mechanism.
:> 
:> I present resource consumption as a real time constraint
:> on the structure of data and on techniques of data access.
: 
: But you do not explain why SELECT * is less resource consuming than
: anything else.

I was trying to explain that a program (being written in Ada or not)
needs to be able to release database resources when proper working of
the database software requires that this be done. If an abstraction
doesn't offer this possibility, then I cannot use the abstraction.

Since I am in no position to discuss the difficult task of designing
a modern database system, I'll leave this to others now. :-)


-- Georg