Re: Windows Ada database support.

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

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?

> 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.

>:>:>: 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.
> 
> Well, the prime goal for me has got to be an application that works
> within the limits set by the RDBMS, in this case Oracle. If I have
> to "descend" to sequential access or to random access via cursors,
> so be it.

You could simply say: we need no generic data base interface.

>:  It is difficult to develop something
>: large, complex and concurrent using only arrays. As a matter of fact.
> 
> Say that to someone you uses one of the array programming languages...
> 
> SQL is much more than just arrays. It also has sets and tables and
> cursors.  Like Ada 2005.
> 
> Indeed RDBMSs have some low level features, but why not? There are
> DBs based on different data structures, like extensible types.
> Nice as they are, they do have real time limits, as a matter of fact.

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

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

Why? 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.

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

> There are
> others who want to use the database, too, so "could you please stop
> shaking hands and give us some of the resources back if you don't
> need them any longer!"

I do not see why exposing, say, tasks should be less effective than hiding
them into connections, transactions whatsoever.

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?
2. Why Ada will be less efficient than SQL?

>: 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.
> 
> I'd leave RDBs only when table views are a burden, not because there
> might be cases.

OK, in data acquisition it is a heavy burden. Customers wish a table
(equidistant time, value1, value2 etc). But the system is event/data
driven. So the table basically contains useless garbage. Yet they still
want it, because tables are so cool.

>: Just look how many DB programmer positions are
>: offered. This is a significant indicator, that the technology is outdated.
> 
> For me the number of database adminstrators/programmers has to do
> with the number of significant installations and the number of
> projects.
> This number depends on the number of organisations, and on their
> willingness/ability to invest. I don't think that the number of
> wealthy organisations will change significantly because some
> programming techniques evolve.

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

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

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