ng**********@rediffmail.com (R. Rajesh Jeba Anbiah) writes:
mf***@fuhr.org (Michael Fuhr) wrote in message news:<3f**********@omega.dimensional.com>...
Or use dbx, avoid using database-specific features, and use a subset
of SQL that's likely to work everywhere. Done correctly, porting
code from one DBMS to another can involve nothing more than changing
the arguments to dbx_connect().
So, it's not a wrapper and so I couldn't understand the use of dbx.
If you want to move to another DB, you need to change the whole code
with some search and replace...
If the application is already written using a database-specific
API, then yes, you have to make global substitutions when porting
to a new database.
I would like to know the real use of dbx. It seems that you've used
dbx successfully... that's why I've decided to ask you the __real__
benefit of dbx.
The benefit of using dbx or any other database abstraction layer
is that you change almost nothing when porting an application to
use a different DBMS: ideally you'd change only one line, the line
that connects to the database. The rest of the application doesn't
know or care whether the database is MySQL, PostgreSQL, Oracle,
Sybase, or whatever. This makes the application more portable and
easier to maintain.
The disadvantage of database abstraction layers is that you can
lose access to features that are by their nature database-specific.
The code might also be less efficient due to the overhead imposed
by the abstraction layer.
Whether the advantages of using a database abstraction layer outweigh
the disadvantages depends on the environment and your priorities.
If the code might have to use different DBMSs, and if the cost of
modifying the code and then testing the changes is expensive, then
using an abstraction layer might be preferable. On the other hand,
if the application is likely to run only in an environment that's
already heavily committed to a particular DBMS, then you might
prefer to use that DBMS's API for efficiency and to gain full access
to its features.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/