Database abstraction layer: Difference between revisions

Revision as of 14:47, 24 October 2019

Revision as of 14:59, 5 December 2019

Line 32:

Alternatively, there are thin wrappers, often described as ''lightweight'' abstraction layers, such as OpenDBX<ref>{{cite web |url=https://www.linuxnetworks.de/doc/index.php?title=OpenDBX |title=OpenDBX |author==<!--Not stated--> |date=24 June 2012 |website=linuxnetworks.de |access-date=26 July 2018}}</ref> and libzdb.<ref>{{cite web |url=http://www.tildeslash.com/libzdb/ |title=Libzdb |author==<!--Not stated--> |access-date=26 July 2018 |year=2018 |website=tildeslash.com}}</ref> Finally, large projects may develop their own libraries, such as, for example, libgda<ref>{{cite web |url=http://www.gnome-db.org/ |title=GNOME-DB |author==<!--Not stated--> |access-date=26 July 2018 |date=12 June 2015 |quote=Libgda library [...] is mainly a database and data abstraction layer, and includes a GTK+ based UI extension, and some graphical tools.}}</ref> for [[GNOME]].

== Arguments for ==

=== SpeedIn favor ===

Software* Development period: software developers only have to know the database abstraction layer's API instead of all APIs of the databases their application should support. The more databases should be supported the bigger is the time saving.

Using* Wider potential install-base: using a database abstraction layer means that there is no requirement for new installations to utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.

As* Future-proofing: as new database technologies emerge, software developers won't have to adapt to new interfaces.

A* Developer testing: a production database may be replaced with a desktop-level implementation of the data for developer-level unit tests.

Depending* Added Database Features: depending on the database and the DAL, it may be possible for the DAL to add features to the database. A DAL may use database programming facilities or other methods to create standard but unsupported functionality or completely new functionality. For instance, the DBvolution DAL implements the standard deviation function for several databases that do not support it.

=== DevelopmentAgainst periodit ===

Any* Speed: any abstraction layer will reduce the overall speed more or less depending on the amount of additional code that has 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.

Software developers only have to know the database abstraction layer's API instead of all APIs of the databases their application should support. The more databases should be supported the bigger is the time saving.

A* 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.

Database* 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 optimizations or debugging features. These problems magnify significantly with database size, scale, and complexity.

=== Wider potential install-base ===

Using a database abstraction layer means that there is no requirement for new installations to utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.

=== Future-proofing ===

As new database technologies emerge, software developers won't have to adapt to new interfaces.

=== Developer testing ===

A production database may be replaced with a desktop-level implementation of the data for developer-level unit tests.

=== Added Database Features ===

Depending on the database and the DAL, it may be possible for the DAL to add features to the database. A DAL may use database programming facilities or other methods to create standard but unsupported functionality or completely new functionality. For instance, the DBvolution DAL implements the standard deviation function for several databases that do not support it.

== Arguments against ==

=== Speed ===

Any abstraction layer will reduce the overall speed more or less depending on the amount of additional code that has 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 optimizations or debugging features. These problems magnify significantly with database size, scale, and complexity.

== See also ==