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!news2.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: Wed, 8 Dec 2004 11:56:31 +0100 Message-ID: References: <5e3e03a7.0411240431.7e037a4e@posting.google.com> <2004112420030750073%david@bottoncom> <11w2chxxtggn9.a442ecwtujd2$.dlg@40tude.net> <1jrbh30djhwuh$.cpwm02mv7d1d.dlg@40tude.net> <18u46qzjs6s8v.19927r9ay0kkh.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net WiphbzImC+TLYzsLPSAplAtI50Hxmjojh9Ty25C+bjPL0ZmV8= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:6837 Date: 2004-12-08T11:56:31+01:00 List-Id: On 08 Dec 2004 11:03:44 +0100, Ole-Hjalmar Kristensen wrote: >>>>>> "DAK" == Dmitry A Kazakov writes: > > DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote: > >> Dmitry A. Kazakov wrote: > >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: > >> : > >> :> Dmitry A. Kazakov 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