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>

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

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.

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

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