Re: Windows Ada database support.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote:
> 
>:> This is interfacing to "world", not to some abstraction.
>  
>: Which only supports the point that cursor might be wrong abstraction.
> 
> Aha.
> 
> Cursors are not an abstraction from the point of view of an Ada
> program.  SQL Cursors are a given part of the "world", in this case, the
> data base system. Go argue with Oracle Corp.

You are mixing abstractions and things [of the "world"]. The goal of an
abstraction is to get rid of things [by replacing them by other, abstract,
things].

>:>   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?

>:>: So what? As long as my application uses Ada.Database, I do not care.
> 
> Is this a motto?

As long as the goal is to have a generic data base interface.

>:> Thick abstractions leave some choices behind. This isn't always helpful.
>  
>: Surely, but statistically irrelevant.
> 
> Aha. But allow me to say, as much as I'd wish to be able to use
> a nice transparent, almost invisible interface to database system,
> I see no base in reality for saying that abstraction thickness is
> statistically irrelevant. For several reasons, and also because
> 
> - cursors do occur, no matter whether you express them behind Ada
>   abstractions or not. Working with snapshots affects performance/
>   shared resources to the point where you can no longer hide them relying
>   on some AI system to free the resources automatically so the system
>   keeps running.

This is a typical lack of abstraction. It is difficult to develop something
large, complex and concurrent using only arrays. As a matter of fact.

This is why thick bindings are so necessary. After all Ada's protected type
is just a thick binding to a chunk of raw memory. You may argue that
X'Address occur, would you?

>   Working with RDBMSs means to have influence on another program's
>   multiply shared data in soft real time! However, your program doesn't
>   control that other program, your program must be well-behaved. Show me
>   how to do this in some Ada.Databases.

The same way we program concurrent distributed applications in Ada! A
transaction is just an equivalent of protected procedure or rendezvous. For
more advanced technique you should have higher abstraction, you should go
ADT, OO, and so get rid of raw table views. Especially because there might
be data bases for which table views could be very inefficient.

> - saying that performance/resources in database systems are statistically
>   irrelevant makes me think that your perspective on DBs is different
>   from mine, and probably not just mine ;-)

Performance is relevant, but you cannot achieve it maintaining that low
level of abstraction. There is just a physical limit of application
complexity for each level. IMO, DB applications have outgrown tables and
cursors long time ago. Just look how many DB programmer positions are
offered. This is a significant indicator, that the technology is outdated.

>: Otherwise we would have no Ada and still were programming in assembly.
> 
> 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. It is a fundamentally flawed argument. The whole history of
computer development is against it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de