Most of those are problems, not solutions.
Databases provide more than just "storage".... If you use them ONLY for storage, you are wasting them and probably reinventing many of these things from scratch or getting them from the OR tool. Thus, the OR tool becomes a half-ass database of it's own.
The OR tool takes over some of those functions because databases are themselves "half-ass" at many of them.
Example:
* Persistence
* State management
* Backup and replication of data
I fail to see how these 3 are different than the term, "storage". But I'll let you have a little padding in your list. Part of my point is that different DB's do replication (for example) differently, and deployers should be free to select a DB for such reasons. Instead, we have developers selecting which DB's they will support.
* Query languages or query ability
* Data computation/processing (such as aggregation and cross-referencing)
* metadata repository
* Access security
* Data rule enforcement or validation
* Multi-user contention management and concurrency (locks, transactions, rollbacks, etc.)
* Multi-language and multi-application data sharing
The last one is the only point I'll consider (multi-language). This is why, for example, many application-layer providers have drunk the XML Kool-Aid lately (although I think XML is overkill). Anyway, many O-R producers these days provide a socketed app that can serve multiple languages, or a DLL, or shared memory, or just connect components from dissimilar languages. It's not a hard problem--there are lots of options.
For the rest, I find it extremely cumbersome to perform any of those tasks within the data store. All of those concern business policies, which are modified often enough that they should be in application-level code. As businesses change, queries change, metadata changes, and security requirements change. Databases are well-known for sucking golf balls when these changes occur--they either:
1) force such concerns into SQL, which isn't powerful enough to handle it, or
2) introduce their own proprietary layer of "metadata", which an application developer then has to write a wrapper for anyway--we're back to the problem of writing Yet Another Wrapper module for each database we wish to support with our app.
both of which lead to
3) hiring another warm body just to manage "the database".
Placing these tasks into an app framework reduces cost, maintenance staff, and time-to-market. To repeat a mantra, "databases should be a commodity by now". If you disagree, then you've been suckling at the DB vendors' teats for too long. Separation of concerns is a Good Thing--DB's rock at storage, and suck at all those other things, doubly so in a hetero environment. One of the reasons they suck is that they try to be all things to all consumers.
