Re: Windows Ada database support.

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
<snip>

    DAK> This is why thick bindings are so necessary. After all Ada's protected type
    DAK> is just a thick binding to a chunk of raw memory. You may argue that
    DAK> 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.

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

The transaction concept is significantly more powerful and complex
than protected procedures or rendezvous mechanisms in programming
languages. Unless your abstraction layer gives you full access to the
complete transaction apparatus in a DB-independent way, it simply
won't fly. You want to abstract away confusing details and differences
in implementation, not simplifying the underlying concept so much as
being unusable.

    >> - 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 ;-)

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

Cursors are somewhat evil, and certainly over-used. Relational algebra
is not on a particularly low abstraction level, and certainly higher
than the typical procedural manipulations you do within a programming
language. It is certainly arguable whether there *are* better
abstractions than the (object) relational model at the moment.
Object-oriented databases certainly are not a better alternative for
most applications.

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

    DAK> It is because you present performance as an argument for using a low level
    DAK> mechanism. It is a fundamentally flawed argument. The whole history of
    DAK> computer development is against it.

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

-- 
   C++: The power, elegance and simplicity of a hand grenade.