In my experience, the best way to go is to keep the complexity as low as possible while mantaining full focus on what you want to do. Will you work alone on the project or will more people work on it? Will you port the project to a different database back-end in the future? How big is the project? how complex its data set?

I usually go for the easiest thing to do that will match nicely the problem space. This is very often avoiding multiple layers of abstractions and objects, unless the project is very big and/or you're prepared to document it all in a apt way. Don't go for a solution that makes solving the problem harder at all, and try to keep separate things that can live one without the others. Don't go for a solution that everybody is chatting about or you read books about just because it's fashionable or academically "in".

One of the reasons why Unix is still around is that it makes it simple to create a "solution toolbox" that something else can then use.... so it makes solving the "big" problem a task of solving smaller ones and the glueing it all together. Re-use what you can, you won't be the first person ever trying to solve the problem you're facing.

Don't go for performace at first; unless your design is infeasible, CPU cycles cost less than your own time. And half-solved computing messes tend to get worse with time. Design for simplicity and understandabilty, play with the problem space, then decide. Perl can be a very good tool about this.

Just my euro 0.02... :-)