Link Details

Voted down for suggesting that database structure is some prerequisite to code. I would rather see my application designed around use cases and user requirements not some rdbms quirks.

I did not mean to suggest that table design is a pre-requisite to code. I meant to state it as an absolute fact.

Well, I guess "The Database Programmer" explain a lot. Just remember that some people build applications, not db frontends.

But in the end you still need a place to store the data for the application, so its still a front end to the data. All an application is, is an interface to data, whether it be photoshop (image data) or a word processor (formatting data) its still a front end. The only way to get rid of the front end would be to write in binary, which I am sure people do not want to do.

Applications you mentioned offer functionality, you don't need them to open images or text files, simpler viewer would do. They would be usability nightmare if you would build them as data frontends. Maybe you were sleeping for past few years, but nowadays an application can talk to web services for example and don't even use any persistent storage. Most application are meant to serve users who don't give a damn where or how you store your data. If you make fundamental decision around your database schema you are doomed to fail, you end up with rigid inflexible design, this is frequent mistake made by people not understanding object oriented programming.

"If you make fundamental decision around your database schema you are doomed to fail,"

My experience is the exact opposite. On this point we are not likely to agree or resolve our disagreements. There is no more I can offer except the experience presented in the entire blog series.

As dorgan points out, all applications are front ends to data, even those you mention that do not appear to be. A spreadsheet is a front-end to spreadsheet data, a viewer is a front-end to data stored on the filesystem, a mashup is front-end to data stored elsewhere, and a conventional database web app is a front-end to data under the programmer's control. Possible exceptions include irc/im (when no logging is taking place), where there is no persistent data -- except for the configuration. In all of those cases your code follows the structure of your source data, or it does not work.

To conclude I would point out the best you can say is that an article on denormalization is not relevant to an application that does not have its own local relational store. All criticisms past that point are themselves irrelevant.