Database abstraction layer: Difference between revisions

Revision as of 10:35, 29 June 2009

Revision as of 13:47, 7 July 2009

Line 13:

== Arguments for ==

===Future-proofing Development period ===

If a system's legacy database backend is outgrown or becomes unusable for some other reason, 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.'' [http://jeremy.zawodny.com/blog/archives/002194.html]

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, ie: new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.

=== Wider potential install-base ===

Using a database abstraction layer means that there is no requirement for new installations in utilise a specific database, ie: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.'' [http://jeremy.zawodny.com/blog/archives/002194.html]

== Arguments against ==

=== Speed ===

Any abstraction layer will function to reduce overall speed (at least in interpreted code environments).

===Masked Operations===

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.

Database abstraction layers may limit the number of available database operations to a subset of those supported by a given database backend. In particular, database abstraction layers may not fully support database backend specific optimisation or debugging features.

=== Dependency ===

A database abstraction layer provides yet another functional dependency for a software system, ie: a given database abstraction layer, like anything else, may eventually become obsolete, outmoded or unsupported.

===Programmer time===

A database abstraction layer provides yet another functional dependency for a software system, ie:i.e. a given database abstraction layer, like anything else, may eventually become obsolete, outmoded or unsupported.

Programmers must learn the database abstraction layer's API.

=== Masked Operationsoperations ===

Database abstraction layers may limit the number of available database operations to a subset of those supported by athe givensupported database backendbackends. In particular, database abstraction layers may not fully support database backend specific optimisationoptimization or debugging features.

[[Category:Application programming interfaces]]