There's no one answer here, except perhaps for "it depends". Use whatever tool is best suited to getting the job done that you need to do while simultaneously trying to be sufficiently forward looking that you do not paint yourself into a corner. Sounds easy, doesn't it?
For most small projects, you probably don't need the high octane solution of hand crafted SQL. As such, pick a good framework and exploit it's abstractions to your advantage. If your requirements start bumping up against the limitations of its feature set, then try looking for another framework that provides the features you need, or perhaps consider contributing to that framework by augmenting its feature set. Of course, the latter might not be an option, as one of the features of a framework may be that it is compact. Simplicity itself can be a feature, and adding too much to a framework can be just as harmful as leaving certain things out.
Of course, even if you decide to implement a roll-your-own solution, you'll probably end up creating a framework of sorts for yourself. You'll see all sorts commonality between various tasks and want to create an abstraction. Beware feature creep.
In reply to Re: Should it be database independent?
by skyknight
in thread Should it be database independent?
by szabgab
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |