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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a0be06fbc0dd71f1
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: The future of Ada is at risk
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <20071229040639.f753f982.coolzone@it.dk> <flnlmp$su$1@online.de>
 <878x3436pj.fsf@ludovic-brenta.org> <1199531506.9355.8.camel@K72>
 <vh1ezr05krrf.1fhfhd3lm8h6a.dlg@40tude.net> <1199539751.9355.46.camel@K72>
 <1xu2jerm6vwjv.mt6we9a8wu5q.dlg@40tude.net>
 <sa41w8v7s3m.fsf@snoopy.microcomaustralia.com.au>
 <pjh0xejxnqdn$.1k74da00vqix8.dlg@40tude.net> <1199621128.7300.72.camel@K72>
Date: Sun, 6 Jan 2008 13:23:12 +0100
Message-ID: <186n1dt34b84r.1jjg9vmd48kbs.dlg@40tude.net>
NNTP-Posting-Date: 06 Jan 2008 13:23:13 CET
NNTP-Posting-Host: 699844b9.newsspool4.arcor-online.net
X-Trace: 
 DXC=B[^F1n8FHQEE4ZB2flKORA4IUK<Cl32<A4Fo<]lROoRAFl8W>\BH3YBaM`ahI7J6NLDNcfSJ;bb[EIRnRBaCd<MNG>oOn`oRN:LUBA2n9o6lJB
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:19239
Date: 2008-01-06T13:23:13+01:00
List-Id: <comp.lang.ada>

On Sun, 06 Jan 2008 13:05:28 +0100, Georg Bauhaus wrote:

> On Sun, 2008-01-06 at 09:42 +0100, Dmitry A. Kazakov wrote:
> 
>>> http://www.djangoproject.com/documentation/model-api/
> 
>> Yes, that looks pretty much like it should be, IMO.
> 
> Did you notice that they provide anyone with direct access
> to SQL in order to do non-trivial relational things?

You can do assembler insertions in Ada. The relation must be same.

Ada design never considered premature, close-to-hardware optimization as a
priority. I don't see why in case of DB, it should be any otherwise.
Further I doubt very much that performance problems could be imposed by
bindings. Usually such problems have algorithmic nature. I don't see how
reasonably designed DB bindings would force you to choose a wrong
algorithm...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de