Database Abstraction

When you have an application that stores its data in an RDBMS, you have interface issues.

• you need to send SQL code to the database

• you get tuples (or lists, or arrays, etc.) back, rather than objects (Object-Relational Impedance Mismatch)

Most languages (e.g. Python) give you a Db Api library which hides some of the connection/interface complexity. But you're still passing SQL etc.

• this note on AdoDb notes that even simple queries (my app uses "limit" lots) can vary across RDBMS engine.

When this interaction happens all over the place in your code, should you be concerned? I'm trying to learn the best approach for my environment.

The code I've inherited barely even uses functions for anything, much less classes, much less classes in other modules.

Conversely, some people make a library/classes to bring all the SQL stuff together.

I don't find that terribly helpful. I find that I don't get much re-use of specific queries I need to make. So having 1 class with 500 methods doesn't seem any better than having 500 functions scattered throughout my app.

At the moment I'm just starting to wrap some of those queries into functions so at least they're better contained and self-documenting...

I'm now reading Martin Fowler's Patterns of Enterprise Application Architecture to assist.

managing Security risk of "SQL injection" http://www.unixwiz.net/techtips/sql-injection.html

SqlObject is an Object-Relational mapper that lots of Python developers are using.