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!npeer.de.kpn-eurorings.net!news.uni-stuttgart.de!carbon.eu.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: 09 Dec 2004 13:22:15 +0100 Organization: Sun Microsystems Message-ID: 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> 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 1102594940 17003 129.159.112.195 (9 Dec 2004 12:22:20 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 9 Dec 2004 12:22:20 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6862 Date: 2004-12-09T12:22:20+00:00 List-Id: >>>>> "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. 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.