Re: Windows Ada database support.

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

On 08 Dec 2004 11:03:44 +0100, Ole-Hjalmar Kristensen wrote:

>>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>     DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote:
>     >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>     >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:
>     >> : 
>     >> :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>     >> :> 
>     >> :>: I think that this is a shortcoming of the very concept of a relational
>     >> :>: view. Relation is not an array. Period.
>     >> :> 
>     >> :> Who says that a relation is an array?
>     >> : 
>     >> : Nobody. The problem is that we need arrays, or more generally, ordered
>     >> : containers. This is the way the most people think about tables.
>     >> 
>     >> Hm. If at the DB level you ask,
>     >> 
>     >> SELECT S.key, T.foo, T.bar from S, T
>     >> WHERE (S.key BETWEEN 100 AND 200)
>     >> AND T.foo = S.key
>     >> ORDER BY S.key
> 
>     DAK> This is the source of the problems in my view. What does SELECT in
>     DAK> application terms? A developer would like to be two storeys above that.
> 
> A good question. But isn't the goal of the application programmer
> precisely to select an implementation of the domain-specific concepts?

Yes, but from one storey below! (:-)) It is essential not to sink in
details.

> So the application programmer cannot really be "two storeys above
> that", he has to choose how to do the mapping to some more general
> representation, be it DB schema or programming language.
> An even better question is what do you want to accomplish, in terms of
> your *problem* domain? It isn't obvious to me that using another
> interface to the DB (object-oriented, navigational, ER-like, etc) in
> general will make the mapping from the problem domain any easier.

So the point is that SQL is the best thing one can imagine? George's point
was, in my interpretation:

SQL is an inevitable evil (mostly because of performance requirements),
higher abstraction is impossible.

Your point seems to be:

Higher abstraction isn't even needed because SQL is the ultimate optimum.

> For
> many application domains, thinking in terms of sets and relations are
> perfectly fine, and going to an object-oriented / navigational model
> and effectively doing your own joins isn't going to help you much.

Again, there are two different questions. I have already formulated them in
another post:

1. Why relations should be handled?
2. Why Ada cannot handle them?

To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no,
because...

Note I do not argue that 1=no. I only suspect that there might be better
ways. But let's agree for a moment that 1=*YES*. Then, what about 2?

> You
> have to implement the relations between your problem-domain objects in
> some way, and the relational model and the use of normailzation has
> proven itself to be a very robust and flexible way of doing this,
> although not necessarily the most efficient.
> 
> If you have a better model for describing the problem domain in mind,
> I'm more than willing to listen.

OK, you wished that! (:-)) I would like to view it as a distributed system
and get rid of the notion of DB altogether. Only persistent objects. No
I/O, just memory-mappings. [ Clearly, in any short term perspective it is
an utopia. ]

> Btw., many years ago I worked on a project where the main goal was to
> develop a rapid prototyping tool for DB applications. The project
> started because a fellow analyst found out that lots of customers did
> not really understand the implications of the ER models he created, so
> he felt the need to rapidly create a set of example applications which
> could illustrate the possibilities of his ER model.  Our approach was
> to first create the ER model, then to create an "application" or form,
> we would select some entity as the root. By following the relations
> from this root entity we could reach other entities, and so on,
> effectively creating a hierarchical structure from the ER network. The
> tool also allowed you to select a subset of the attributes for each
> entity.

Nice.

> The DB schema was automatically created from the ER model,
> and the prototyping tool also generated descriptions of the logic (in
> terms of interpreted code and SQL) and a graphical user interface for
> each application. The actual execution of the application was done by
> an interpreter, in order to give us rapid turnaround time (just
> seconds to make changes to your application or schema and try it
> again), but of course you could just as well have created data type
> definitions and access functions in a compiled language to allow an
> application writer easy access to the ER model/DB schema through a set
> of application-specific interfaces.

Excellent. Why something like that cannot become Ada.Databases?

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