On 2008 Feb 27, at 12:11, John Cowan wrote:
In reality, though, I think portability between databases is more
hypothetical than real. Projects typically start with one database
and
stick to it, for moving between databases *even if a portability layer
is in use* turns out to be hard -- all sorts of stuff outside the main
code base ends up changing (path names, load scripts, whatever).
Agreed. Not only the API but even the dialect of SQL in use changes
enough that one must review all the DB code in an application when the
underlying DBMS changes. (Even when the old API works with the new
DBMS, performance may be so abysmal that a rewrite is still necessary.
I remember consulting with a team who were shocked when I told them that
although you CAN use ODBC with Oracle, you really really don't want to.
Switching from ODBC to OCI resulted in a 40% performance increase
for their mid-tier server.)
That said, a DBI is still useful, for several reasons. First, management
may not have decided which DBMS is to be used, or may reverse their
decision at an inopportune time. Whether prototyping or doing early
production development, a DBI can be very useful. Second, I have
taught database classes, and grew to love the fact that a DBI helps
people learn the concepts without getting into a messof stuff that's
not really relevant.
-- vincent
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
