Database abstraction layer: Difference between revisions

Revision as of 15:51, 13 March 2013

Revision as of 18:22, 2 April 2013

Line 3:

== API level abstraction ==

Libraries 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. TheAs all [[SQL]] dialects are similar to one another, application developerdevelopers can choose fromuse all the language features, butpossibly has to provideproviding configurable statementselements for queryinga ordatabase-specific changingcases, tablessuch as, typically, user-IDs and credentials. OtherwiseA histhin-layer applicationallows wouldthe alsosame bequeries tiedand statements to onerun on a variety of database products with a negligible overhead.

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 (computer science)|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.

Examples of thin database abstraction layers include [http://www.linuxnetworks.de/doc/index.php/OpenDBX OpenDBX] and [http://libdbi.sourceforge.net/ libdbi].

== Language level abstraction ==