From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,bf02c238a92156a3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Windows Ada database support. Date: Thu, 9 Dec 2004 15:03:12 +0100 Message-ID: <1gontmpcus5kl.3fhaa7wwj8ee.dlg@40tude.net> References: <5e3e03a7.0411240431.7e037a4e@posting.google.com> <11w2chxxtggn9.a442ecwtujd2$.dlg@40tude.net> <1jrbh30djhwuh$.cpwm02mv7d1d.dlg@40tude.net> <18u46qzjs6s8v.19927r9ay0kkh.dlg@40tude.net> <1bucyi24j39vb.14y21qffgez47.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net IwWL8f8njORYkbjjKFqDbwMcTxOG0C/e7dPyrGjdJOunY2C/g= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:6866 Date: 2004-12-09T15:03:12+01:00 List-Id: On 09 Dec 2004 13:22:15 +0100, Ole-Hjalmar Kristensen wrote: >>>>>> "DAK" == Dmitry A Kazakov writes: > > > >> > >> 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