Re: Windows Ada database support.

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

On 09 Dec 2004 13:22:15 +0100, Ole-Hjalmar Kristensen wrote:

>>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
> <snip>
>     >> 
>     >> Dmitry, what is your plan the other way round, i.e. how do you
>     >> make data related expressions for some nice higher level abstraction?
> 
>     DAK> You have cunningly formulated the problem so that there is no higher level!
>     DAK> (:-)) There is either:
> 
>     DAK> for I in S'Range loop
>     DAK>    if S (I).Key in 100..200 then
>     DAK>       for J in T'Range loop
>     DAK>          if T (J).Foo = S (I).Key then
>     DAK>             Append (Result, S (I).Key, T (J).Foo);
>     DAK>          end if;
>     DAK>       end loop;
>     DAK>    end if;
>     DAK> end loop;
> 
>     DAK> or you define "*" (product) for the type Table'Class (of S and T) + other
>     DAK> operations to extract sets from the tables.
> 
>     DAK> But the question is why an application should always organize its data in a
>     DAK> way which could require implementation these, very expensive, operations?
>     DAK> Isn't it so that tabular view just forces global container operations? When
>     DAK> we write in Ada we avoid global operations. How often you copy an array in
>     DAK> Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays?
>     DAK> Isn't S and T just a two-dimensional array?
> 
> Yes, and you have generic tools to follow relations (join). But There
> *are* reasons for organizing your data this way *in the database*.
> This organization is very flexible, but as you observe, may be
> expensive. SQL compilers have do do lots of optimizations to allow
> efficient execution of complex queries, especially since a large
> database is orders of magnitude bigger than the amount of available
> memory. The basic idea is that you organize your data in a way that
> captures the aspects that are inherent to the data domain itself, not
> specific to any particular application. This data model (the
> conceptual schema) can then support a very large set of different
> applications with no need to reorganize the data model. This is much
> more flexible than the old network databases, where the access paths
> (indices, pointers) were hard-coded into the data model, giving
> excellent performance for some applications, and absolutely abysmal
> for others, in addition to being hard to maintain. In the three-schema
> architecture, each different application is then supported by a
> different external schema, typically a subset or a transformation of
> the conceptual schema. The application itself need not organize its
> internal structures as tables, but having a sound conceptual view and
> a normalized structure is really a necessity if your database is going
> to support a multitude of applications. This line of thinking
> obviously originates from corporate databases and the like, where
> there is a need to maintain a large body of data *independently* of
> the applications which may happen to use them.

Right. They have a giant garbage container and just throw everything in.
The applications have to sort out. (:-)) This approach is efficient no
longer the variety of applications remains very limited. What does anything
just a bit more complex than a business application? It packs everything in
blobs!

> I think you see the
> similarites between the three-schema architecture and the rapid
> prototyping tool I described earlier. It is not a coincidence :-)
> 
> Now think of this: *IF* set operations were supported by the
> programming language, wouldn't it be a convenient way of structuring
> your code (efficiency considerations aside)? Example: I want to update
> the salaries of all employees with a specific manager, or I want to
> see which projects an employee has worked on in the last month, or
> find the sum of all hours employees working for a specific manager has
> worked on a specific project. These are all problems which can be
> trivially solved using sets. No navigation or hard-coded links
> necessary, no need to create objects which maintain the relation
> links, no need to add new classes when you want to add a new relation
> between objects or when your relation changes from on-to-one to
> one-to-many or many-to many. This is taken care of by modyfying the
> integrity constraints of your schema. The inherent relations in your
> problem remains the same whether you prefer a solution with explicit
> links (the most typical for object-oriented solutions, in my
> experience), or a tabular organization, in which case you will most
> likely use the DBMS engine to do the bulk of the processing. One way
> of looking at the difference is that with a tabular organization the
> application is free (via set operations) to follow or update any
> thinkable relation, limited only by the integrity constraints, while
> in an object-oriented or network system, you will typically have
> materialized those relations you are interested in, and the
> constraints are implicit in your materialization. 

True. But also, nothing prevents us (with MI) from providing a relational
view for containers. Comparison with Ada: the major problem with
Unbounded_String is that it does not implement the abstract array
interface. This prevents us from writing generic applications working for
both String and Unbounded_String.

Probably there is no ideal interface for all cases. But OO (or ADT) design
could simultaneously provide support for many views. It seems that vendors
of non-relational data bases have no great problems with implementing SQL
and ODBC for their products.

> But there clearly is a mismatch between the facilites provided by the
> RDBMS and your typical programming language, I am just unsure what is
> the best way to bridge that gap.

To take a look at the calendar! (:-))

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