Database abstraction layer: Difference between revisions

Revision as of 01:10, 30 May 2014

Revision as of 17:56, 21 September 2014

Line 1:

{{UnreferencedRefimprove|date=DecemberSeptember 20082014}}

A '''database abstraction layer''' is an [[application programming interface]] which unifies the communication between a computer application and [[database]]s such as [[MSSQL|SQL Server]], [[IBM DB2|DB2]], [[MySQL]], [[PostgreSQL]], [[Oracle database|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 or she 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. If an application has such a layer built in, it is called '''database-agnostic'''.<ref>http://searchdatamanagement.techtarget.com/definition/database-agnostic</ref>

Line 11:

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

Line 24 ⟶ 25:

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