This page sprang from reading a paper given at VLDB 2000, the conference of the VeryLargeDatabaseFoundation.
Download a PDF of the paper from http://www.acm.org/sigmod/vldb/conf/2000/P001.pdf
http://www.vldb.org/dblp/db/conf/vldb/ChaudhuriW00.html "Rethinking Database System Architecture: Towards a Self-Tuning RISC-Style Database System"
The points made by Chaudhuri and Weikum are as follows (their bullet points)
- Featurism drives products beyond manageability. (e.g. new joins being added to database for marketing reasons)
- SQL is painful. (generalizing from the OO-Relational mapping problem, everyone has a problem with SQL in that they learn it for one and only one reason: to access relational databases. It's not your day job)
- Performance is unpredictable.
- Tuning is a nightmare and auto-tuning is wishful thinking at this stage.
- We are not alone in the universe. (meaning typical apps need to make the DBMS coexist with other kinds of server)
- System footprint is considered harmful. (major DBMS vendors are typically not marketing to those in restricted resource environments)
- System-oriented database research is frustrating. (this was a comment that it is becoming increasingly impossible to produce anything new and useful in the DBMS world without being directly employed by a vendor. The traditional approach requires too much of university researchers who are looking elsewhere to make bigger strides)
The writers go on to talk about maintenance costs etc and suggest that the DBMS world is in crisis. They point out that most projects don't need a full on DBMS and could do with something simpler and more reliable (and cheaper). Following from this they suggest that for the most part we could live with NetApp
?-style 'network bricks' providing database functionality, without SQL, and make 'auto-tuning' the main goal instead of adding features. Auto-tunable systems are limited to fairly simple DBMS implementations, but this is all most of us need.
Its an interesting paper, you should read it in full rather than dismiss this halfbaked summary (it is aimed at a general technical audience).
See also: MultiParadigmDatabase SufficientlySmartDatabase