If a system's legacy database backend is outgrown or becomes unusable for some other reason (e.g. speed or database size) then the time needed to replace the underlying database engine can be rapidly reduced.
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 ==
Line 35:
=== Masked operations ===
Database abstraction layers maylikely 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. These problems magnify significantly with database size, scale, and complexity.
