Looking at vacuum ads from 1950 almost makes one want to be purchasing a new vacuum cleaner. Everything was so wonderful. People were so happy. Life was simple and getting easier with every purchase of an electric appliance. Somewhere, post war heroes were arriving at the vacuum cleaner factory early in the morning wearing hats. They would happily assemble vacuum cleaners all day so they could buy appliances for their coiffed 'home-maker' wives, who were themselves rapidly assembling future baby boomers.
Appliances truly are wonderful because I don't have to think about how they work; I don't have to solve anything. I love the dish washer. I put in dirty dishes. A few hours later I pull out clean dishes. Oh! The new mini cookies that replace dish washer soap are so cool! It nearly makes me want to do the dishes just so I can take the little cookie out of its plastic wrapper and put it to bed in its little drawer in the dishwasher door.
Database servers can be viewed as an appliance. They run on their own like a dishwasher. Four commands are all you need: insert, update, delete, and select like controls on a front panel. You put in data and then pull it out again, sorted or joined with other happy factoids. Somewhere else the DBA makes sure all the factoids get backed up regularly. It is all planned, organized, and full of happy, efficient factoids like a community designed by Walt Disney.
Popular Object Relational Mapping (ORM) tools strengthen the appliance image of the database server. These tools look at the tables you built on the database and then create the object-oriented code you need for your CRUD (hip nerd-speak for create, read, update, and delete). Tools like Ruby on Rails take the appliance image one step further, taking the database table to an AJAX web interface faster than you can run a mile.
From the beginning, database servers were intended to be trouble-free and easy to use. The father of the relational database model, Ted Codd, was trying to make a database something that could stand alone apart from the application. His primary goal was the independence of the database from the application. His paper from 1970 states in the introduction, In contrast, the problems treated here are those of data independence - the independence of application programs and terminal activities from growth in data types and changes in data representation and certain kinds of data inconsistency which are expected to become troublesome even in nondeductive systems. Admittedly, Dr Codd's idea of easy to use or easy to understand may have been different from the rest of us.
Like a good summer novel, there is a subtle, nagging problem lurking. Many programmers have experienced nothing but the database as an appliance that makes their work short and their romantic interludes long. But in smoky bars and dark alleys one finds a few programmers with very different experiences. These programmers talk in raspy voices about performance problems, object-relation impedance, and even deadlocks. These are the survivors of death marches; projects that started out as just another walk in the park but turned into nightmares of changing specifications, long hours, unhappy customers, and growing site popularity followed by horrible performance problems.
These tales are true stories. Performance demands unravel the 1950's image of the database as an appliance. Older, battle-scarred programmers are like post-modern critics of the simple, modern hope. Databases can work like appliances under reasonable demands. But the database server as an appliance is not the unadulterated truth some confident voices make it out to be.
The modern view of a database allows Ruby on Rails or the latest Java Framework to connect database tables to an AJAX web client and everyone is thrilled at how little time it took. Framework developers all claim they have finally found Fred Brooks' silver bullet. They begin to extrapolate on the trend of modern technology and wonder how many decades before vacations to the moon will be affordable to what used to be called the middle class. The Post Modern skeptic acknowledges the power of modern hardware and its ability to hide yesterday's performance problems up to a breaking point. The Post Modern skeptic believes design problems will always be difficult, which is what Fred Brooks actually said. The Post Modern skeptic accepts the truth.