On Fri, 30 Jan 2004, Benjamin Geer wrote:

> >  It was already discussed here. The conclusion was: BAD IDEA. No
> > way to work efficiently with different DBs using the same
> > approach.
>
> 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).

 And what's a problem? Write a portable layer, which provides
YOUR application-oriented abstractions. Writing database-related
sub-layer would be easy enough yet, but you will not pay the
price of the efficiency.

> We simply cannot afford to rewrite and maintain all our
> database-related code for every one of those databases.

 It can't be so large. Fine-grained layer always contains no more
then a dozen of low-level entities.

>  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.

 I've heared a lot of evil words from the industry programmers
about the "good enough" efficiency of the JDBC. And, they're even
have no alternatives, poor ones...

>  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.

 You may provide one, your own, which is limited to the standard
JDBC-like abstraction level, it would be easy to support, if you
don't want to write a higher level abstractions (don't forget -
you'd pay much more for the problems with SQL incompatibility -
so there is no damn need in the JDBC-level layers at all). But
why the maintainers of that DB bindings, like me, would follow
someones "standard" limitations?


-------------------
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