Re: Windows Ada database support.

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

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

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

    >> Then you have in Ada.Container terms,
    >> function Floor (Container : Map;
    >> Key       : Key_Type) return Cursor;
    >> 
    >> function Ceiling (Container : Map;
    >> Key       : Key_Type) return Cursor;
    >> where
    >> S.key >= 100  can be made the floor
    >> and
    >> S.key <= 200  can be made the ceiling.

    DAK> You are thinking in terms of SQL. From this point of view nothing or very
    DAK> little could be done. And after all, GNADE provides embedded SQL for that
    DAK> stuff.

He may just as well be thinking in terms of sets and relations. SQL is
just a slightly clumsy way of conveying those thoughts to the DB
engine :-)

<snip>

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