intense DBA and RDBMS bashing
I fail to see how these 3 are different than the term, "storage".
How exactly do you define "storage" then? Disk? RDBMS don't have to be based on disk. Many of them cache stuff in RAM, automatically. When I do an UPDATE query, I don't have to care about disks and caches in most cases. It is you OO'ers that seem to make a distinction between disk and RAM "state".
force such concerns into SQL, which isn't powerful enough to handle it
SQL is not meant to do *all* processing, nor does it have to in order to be useful. It is called "divide-and-conquer": The DBMS does what it does best and let code do the rest. It is not an all-or-nothing thing nor does it have to be.
Perhaps you just don't know how to use RDBMS effectively and would rather reinvent a tool rather than use one.
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.
Like I said elsewhere, I am not yet convinced that an API can nearly completely wrap SQL except for the trivial. Even if one could, it does not have to be an OO wrapper and does not have to be an OR-mapper. A better solution from an app developer's perspective would be to target a specific dialect of SQL and then have something translate it to specific vendor dielects.
hiring another warm body just to manage "the database".
DBA's often do useful things such as tune performance, manage backups, make sure good schema design is used, apply data integrity rules, and that normalization is applied. Good normalization is pretty much the same as "once-and-only-once", which should be done on ANY "noun model".
Most biz data is used by multiple applications in multiple languages. Either you maddly replicate all over the place, or you hire SOMEBODY that does DBA-like work to manage the central repository. Whether you give them another name or divide up those tasks amoung app developers, somebody has to do it.
Placing these tasks into an app framework reduces cost, maintenance staff, and time-to-market.
If you want RAD and don't give a crap about sharing the data with other systems and tools (for whatever odd reason), then use FoxPro with native DBF files.
