Database Abstraction Problems
by
einhverfr
·
· Score: 4, Insightful
Database abstraction on the language level poses some real problems. For example:
1: PostgreSQL's result set is not forward only. This can be helpful sometimes. Most others are.
2: Interbase stores table names in upper case.
3: Timestamp formats vary per rdbms, and some other aspects of SQL syntax do as well (; or go, for example).
4: MySQL has no equivalent of roles.
I much prefer to work with a database abstraction layer which is a set of function libraries, yet still have the option of rewriting them to take advantage of the unique features of a given database. I can then wrap the behavior of the rdbms' which don't conform.
There are many OO and non-OO database abstraction schemes out there. I have even written my own which is tuned for abstraction and performance and so is procedural rather than OO. But my point is that this allows greater freedom and flexibility.
Database abstraction on the language level poses some real problems. For example:
1: PostgreSQL's result set is not forward only. This can be helpful sometimes. Most others are.
2: Interbase stores table names in upper case.
3: Timestamp formats vary per rdbms, and some other aspects of SQL syntax do as well (; or go, for example).
4: MySQL has no equivalent of roles.
I much prefer to work with a database abstraction layer which is a set of function libraries, yet still have the option of rewriting them to take advantage of the unique features of a given database. I can then wrap the behavior of the rdbms' which don't conform.
There are many OO and non-OO database abstraction schemes out there. I have even written my own which is tuned for abstraction and performance and so is procedural rather than OO. But my point is that this allows greater freedom and flexibility.
LedgerSMB: Open source Accounting/ERP