Avoiding the Kitchen Sink Database

You write an app, you add a database to store the apps's data. Seems simple enough. Over the years, though, the database scheme can quickly grow to become an untamed beast that makes you cry at night: adding extra columns that are really a cache of computed properties or extra tables to normalize some relationships needed in the UI. The database contains critical user data, yet can become the most hacked part of your code to correctly handle migrations and sync.

The problem is your database is used both for storing critical data and for displaying that data and managing the UI. Your data model is torn between two antagonistic goals, and you have a kitchen sink database. Charles proposes a different approach where you explicitly separate those two functions, and which was successfully applied to architect two apps he worked on.