Revision as of 18:22, 2 April 2013 edit Ale2006 (talk \| contribs) Extended confirmed users 1,560 edits →API level abstraction: examples: OpenDBX and libdbi ← Previous edit		Revision as of 22:48, 8 April 2013 edit undo Yobot (talk \| contribs) Bots 4,733,870 edits m WP:CHECKWIKI error fixes using AWB (9075) Next edit →
Line 13: == 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 20 ⟶ 21: === Future-proofing === === Developer Testing === A production database may be replaced with a desktop level implementation of the data for developer level unit tests. == 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.

Database abstraction layer: Difference between revisions