From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA12005; Fri, 30 Jan 2004 12:14:15 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA11949 for ; Fri, 30 Jan 2004 12:14:14 +0100 (MET) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i0UBEDP04079 for ; Fri, 30 Jan 2004 12:14:13 +0100 (MET) Received: from fichte.ai.univie.ac.at (markus@localhost [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0UBEDHn014130; Fri, 30 Jan 2004 12:14:13 +0100 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-6.6) id i0UBECO3014129; Fri, 30 Jan 2004 12:14:12 +0100 Date: Fri, 30 Jan 2004 12:14:12 +0100 From: Markus Mottl To: Benjamin Geer Cc: OCaml Subject: Re: [Caml-list] PostgreSQL-OCaml 1.0.1 Message-ID: <20040130111412.GA13464@fichte.ai.univie.ac.at> Mail-Followup-To: Benjamin Geer , OCaml References: <20040128232131.GA22126@fichte.ai.univie.ac.at> <20040129200653.GA14321@redhat.com> <4019F0B1.6050204@gradient.cis.upenn.edu> <401A30ED.6090007@socialtools.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <401A30ED.6090007@socialtools.net> User-Agent: Mutt/1.4.1i X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 1.0.1:01 abstraction:01 api:01 low-level:01 abstraction:01 caml:01 mottl:02 mottl:02 concrete:02 financial:96 wrote:03 interface:03 library:03 library:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 30 Jan 2004, Benjamin Geer wrote: > In the company I work for (a large financial software vendor), the > unanimous answer would be 'we don't care if it's less efficient; > nothing else is acceptable.' Our customers insist on being able to > use our products with whatever database they prefer (and certainly > our competitors' products can do this). We simply cannot afford to > rewrite and maintain all our database-related code for every one of > those databases. For us (and, I think, for most software vendors, > certainly all the ones I've worked for) the additional abstraction is > well worth a slight loss of efficiency. It is quite efficient enough > for us. The lack of a standard database API is one of the things that, > unfortunately, would make it very difficult for me to convince my boss > to let me use Caml. Having followed the discussion for a while now, I'd say that it's probably best to keep the development of drivers for specific databases and the abstract layer separated. If anybody needs top performance, they can always use the low-level library, but, as is obvious, some people really need more abstract layers. Sometimes flexibility is better than efficiency. Developing a good abstract library for accessing databases is a challenging task, much more difficult than writing a concrete one for some specific database. I think people shouldn't go overboard with abstraction here, and should rather try to develop a unified interface for a given set of widely used databases, e.g. PostgreSQL, MySQL, Oracle. Regards, Markus -- Markus Mottl http://www.oefai.at/~markus markus@oefai.at ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners