This article provides insufficient context for those unfamiliar with the subject. |
A database abstraction layer is an application programming interface which unifies the communication between a computer application and databases such as MySQL, PostgreSQL, Oracle or SQLite. Traditionally, all database vendors provide their own interface tailored to their products which leaves it to the application programmer to implement code for all database interfaces he would like to support. Database abstraction layers reduce the amount of work by providing a consistent API to the developer and hide the database specifics behind this interface as much as possible. There exist many abstraction layers with different interfaces in numerous programming languages.
API level abstraction
Libraries like OpenDBX unify access to databases by providing a single low-level programming interface to the application developer. Their advantages are most often speed and flexibility because they are not tied to a specific query language (subset) and only have to implement a thin layer to reach their goal. The application developer can choose from all language features but has to provide configurable statements for querying or changing tables. Otherwise his application would also be tied to one database.
Popular use for database abstraction layers are among object-oriented programming languages, which are similar to API level abstraction layers. In an object oriented language like C++ or Java, a database can be represented through an object, whose methods and members (or the equivalent thereof in other programming languages) represent various functionalities of the database. They also share the same advantages and disadvantages as API level interfaces.
Language level abstraction
An example of a database abstraction layer on the language level would be ODBC. ODBC is a platform-independent implementation of a database abstraction layer. The user installs specific driver-software, through which ODBC can communicate with a database or set of databases. The user then has the ability to have programs communicate with ODBC, which then relays the results back and forth between the user programs and the database. The downside of this abstraction level is the increased overhead to transform statements into constructs understood by the target database..
Arguments for
Development period
Software developers only have to know the database abstraction layer's API instead of all APIs of the databases his application should support. The more databases should be supported the bigger is the time saving.
Wider potential install-base
Using a database abstraction layer means that there is no requirement for new installations in utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.
Future-proofing
If a system's legacy database backend is outgrown or becomes unusable for some other reason (e.g. speed or database size), then database abstraction layer supporters claim that it can be rapidly replaced. This is not without debate, however. Firstly, it assumes that the database abstraction layer properly supports a viable alternative. Secondly, some people call in to question whether this type of decision is good engineering practice. For instance Jeremy Zawodny (Yahoo, Craig's List, Friendster, Technorati, Rackspace, LiveJournal) states That's bullshit. It's never easy. ... If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice. [1]
Arguments against
Speed
Any abstraction layer will reduce the overall speed more or less depending on the amount of additional code that have to be executed. The more a database layer abstracts from the native database interface and tries to emulate features not present on all database backends, the slower the overall performance. This is especially true for database abstraction layers that try to unify the query language as well like ODBC.
Dependency
A database abstraction layer provides yet another functional dependency for a software system, i.e. a given database abstraction layer, like anything else, may eventually become obsolete, outmoded or unsupported.
Masked operations
Database abstraction layers may limit the number of available database operations to a subset of those supported by the supported database backends. In particular, database abstraction layers may not fully support database backend specific optimization or debugging features.