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!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: 30 Nov 2004 14:46:13 +0100 Organization: Sun Microsystems Message-ID: References: <5e3e03a7.0411240431.7e037a4e@posting.google.com> <2004112420030750073%david@bottoncom> <17w0jtt2xq2ya.1nj2623n37457.dlg@40tude.net> <1ohmhrsp481iu.w61dt6dz9cqk$.dlg@40tude.net> <1cxufyzpjc6ns.1lomm6dpfxyhb$.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 1101822377 2669 129.159.112.195 (30 Nov 2004 13:46:17 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 30 Nov 2004 13:46:17 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6663 Date: 2004-11-30T13:46:17+00:00 List-Id: >>>>> "DAK" == Dmitry A Kazakov writes: DAK> This is why thick bindings are so necessary. After all Ada's protected type DAK> is just a thick binding to a chunk of raw memory. You may argue that DAK> X'Address occur, would you? >> Working with RDBMSs means to have influence on another program's >> multiply shared data in soft real time! However, your program doesn't >> control that other program, your program must be well-behaved. Show me >> how to do this in some Ada.Databases. DAK> The same way we program concurrent distributed applications in Ada! A DAK> transaction is just an equivalent of protected procedure or rendezvous. For DAK> more advanced technique you should have higher abstraction, you should go DAK> ADT, OO, and so get rid of raw table views. Especially because there might DAK> be data bases for which table views could be very inefficient. The transaction concept is significantly more powerful and complex than protected procedures or rendezvous mechanisms in programming languages. Unless your abstraction layer gives you full access to the complete transaction apparatus in a DB-independent way, it simply won't fly. You want to abstract away confusing details and differences in implementation, not simplifying the underlying concept so much as being unusable. >> - saying that performance/resources in database systems are statistically >> irrelevant makes me think that your perspective on DBs is different >> from mine, and probably not just mine ;-) DAK> Performance is relevant, but you cannot achieve it maintaining that low DAK> level of abstraction. There is just a physical limit of application DAK> complexity for each level. IMO, DB applications have outgrown tables and DAK> cursors long time ago. Just look how many DB programmer positions are DAK> offered. This is a significant indicator, that the technology is outdated. Cursors are somewhat evil, and certainly over-used. Relational algebra is not on a particularly low abstraction level, and certainly higher than the typical procedural manipulations you do within a programming language. It is certainly arguable whether there *are* better abstractions than the (object) relational model at the moment. Object-oriented databases certainly are not a better alternative for most applications. >> : Otherwise we would have no Ada and still were programming in assembly. >> >> What has Ada versus Assembly got to do with resource consumption of >> communicating programs (Ada program <-> database program?) DAK> It is because you present performance as an argument for using a low level DAK> mechanism. It is a fundamentally flawed argument. The whole history of DAK> computer development is against it. DAK> -- DAK> Regards, DAK> Dmitry A. Kazakov DAK> http://www.dmitry-kazakov.de -- C++: The power, elegance and simplicity of a hand grenade.