First of all, I don’t “abstract away” a database too much. I am probably going to write the application against a single database platform such that I probably will never change it. (If I did, I would select DBIx::Class.)
What I am going to abstract-away is anything that cares what the particular column-name is; whether some business fact is captured by value x occurring in column y of table z. I really want there to be just one piece of software in my application that “has to know” this.
Because, you know, if my code is littered with many copies of logic that queries the customer table and queries customer_type and checks for the value 'SC' to determine that the customer is a senior-citizen ... the true bugaboo is not precisely how I said that all those different times, but rather that I said it so many times in so many places. That is what’s going to blossom into a maintenance problem that’s gonna bite me in the asterisk, no matter how exactly I said it. A database table is not a business object. You need to heavily and constantly focus your attentions on: “what determinations are made, not how they are expressed in the current data model.”
to determine that the customer is a senior-citizen ... the true bugaboo is not precisely how I said that all those different times, but rather that I said it so many times in so many places.