Editing Database abstraction layer (section)

=== In favor ===
* 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.
* 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.