Ok, maybe the title is a little provocative, but here is the thought. 100% of the work that I do, plan to do, and have done in the past have dictated the database to be used. A lot of CF devs are pushing the use of DAOs as a way to encapsulate the interaction between their business objects and the database. The argument goes that it's easier to swap out the database, roll a new set of DAOs and you're back in business.
For some projects this is probably true, especially when you need your project to support multiple databases (MSSQL, ORACLE, etc.) out of the gate. You let the user/administrator set a switch for the type of db and the code is already in place. This makes a lot of sense when you are building an application that you plan on distributing.
For the type of work that I do, this looks like a lot of extra work for little or no gain when the db choice is stable and your app has little chance of seeing any kind of distribution.
For me, just adding the CRUDS (create, read, update, delete, save) methods to the business objects themselves seems to work just fine and reduces the size of the app. As long as they are done consistantly and in roughly the same place, I don't really see a down side. If you found that you had to change to support multiple dbs down the road, it's not really that much trouble to strip the functions out and set up DAOs if needed, although it's a little more work than if you had set it up that way from the beginning.
Is this too short-sighted?