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!news3.google.com!news.glorb.com!newsfeed-east.nntpserver.com!nntpserver.com!newsfeed1.sea.pnap.net!newsfeed2.sea.pnap.net!newsfeed.pnap.net!brmea-news-1.sun.com!news1brm.central.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: Windows Ada database support. Date: 08 Dec 2004 11:03:44 +0100 Organization: Sun Microsystems 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> NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1102500229 18156 129.159.112.195 (8 Dec 2004 10:03:49 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 8 Dec 2004 10:03:49 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6836 Date: 2004-12-08T10:03:49+00:00 List-Id: >>>>> "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? 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 :-) -- C++: The power, elegance and simplicity of a hand grenade.