> object and xml databases are a more
> natural fit for most use cases
What do objects and XML have to do with use cases? I've yet to see a correlation.
> relational ones, which are built for
> efficiency of execution, not development
> and maintenance.
Relational is built to encode business rules and constraints, to attain flexible queries and ensure data integrity. Efficiency is what drove SQL to prominence as a pseudo-relational language.
> RDMBSs are useful for
> large corporations and have tailor-made
> solutions for almost every statistical
> analysis scenario, but are not as aptly
> applied to web development,
What? Why? Web development, as far as I know, presents data to users. It's not all XML, not that an XML output would influence the underlying data store.
> applications/appliances, distributed
> services or even what databases are
> designed for : persistence and
So relational is not aptly applied to "persistence"? Do you have any actual reasoning behind the above? I see a lot of vague assertions without argument or example.
> relational databases are basically
> 2-dimensional matrices with pointers...
Not really. There are no pointers, quite the opposite - logical deductions (aka selects, joins) are done via VALUES.
> high-class spreadsheets.
> object and xml
> databases are more likely to accept the
> architectures and data models you're
> working with every day,
1. What does a database have to do with "accepting an architecture"?
2. The data model determines the database, not vice versa. Objects are not a data model.
> and are more
> adaptable, flexible and customizable :
Doubtful. If App A directly "persists" its objects, how valuable are they likely to be to App B? If you're talking about a single app maintained by a single programmer with no need to access any of its data beyond its code, then you may be right. Then again, I've never met such an app with a shelf life greater than 3 months.
> you'll be able to apply extreme
> programming principles and add fields as
> you go,
That can be easily accomodated by even SQL DBMSs.
> connect to other systems
What does that have to do with the DBMS?
> maintain focus on your data model and
> your project, not that of the database
> and the best possible model that fits
> into that database.
Agreed that SQL DBMSs don't offer the full power of relational, but they certainly offer an order of magnitude more power than XML and OODBMSs.
> before choosing to ignore this
> suggestion and go back to relational
Go back? I wish. Go forward is more like it.
> struggling to fit your
> designs into its data model,
This is truly putting the cart before the horse. Apparently your apps aren't much concerned with data; in every company in which I've ever worked, the data was gold, the applications mere mining equipment. The data is what your business wants to create, maintain, extract, and transform. Ignoring that in favor of whatever "data-independent" design you've cooked up is nonsense. You either do a conscious data design, or an unconscious one that's crap will emerge, awkwardly.
> xml and object databases.
They've been considered and rejected by those with some fundamental knowledge; the uninformed plow away with XML "data mapping" code that's uglier than the ugliest ADO or JDBC possible.
> from/to RDBMSs is straightforward,
You just said we wouldn't need RDBMSs, didn't you?
> has been set up in real-time
What does real-time have to do with this?
> to truly
> garner the design/maintenance benefits
> of OODBMSs
What design/maintenance benefits? Being able to "persist" something without really caring what that something is? That's design avoidance, and a maintenance nightmare.
> while retaining the atomicity
> and existing relational tools without
> sacrificing data quality and currency.
XML and OODBMSs both sacrifice data quality, by forcing the data to fit a single application at the expense of future "use cases" and application to the needs of multiple users.