Filmed at https://2019.dotswift.io on January 28th in Paris. More talks on https://dotconferences.com/talks 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 I worked on.