A canonical model, or normalized database schema, will not allow you to scale. As you add indexes for performance of queries, your inserts and updates deteriorate in performance. The only way out is to break the normalization scam that DBAs are still milking. The easiest way to do that is to adopt ledger for state. #EventModeling #EventSourcing
@adymitruk a rigid database schema will also eventually severely impede your ability to add functionality as your product evolves (this is perhaps the more relevant form of scalability for many apps).
@adymitruk How many times does one hear "Trying to get this DB migration done, no impediments" at standup? DB migrations *are* impediments!
@leviramsey @adymitruk so help me out, guys. what does it look like in the real world to update your schema and data from event streams?

@adymitruk @brandonmull @leviramsey

You don’t update data of events, they are immutable facts of the past. You can add information in your interpretation of past events if it is possible to use a default value. That’s the same with classical storage, because you can’t magically let missing information appear from nowhere.

Schema updates: Depends on what change you have in mind, can you elaborate!?

@TonyBologni @brandonmull @leviramsey I wasn't implying that past events are modified
@adymitruk @leviramsey @brandonmull I replied to brandon ;-)
@TonyBologni @leviramsey @brandonmull I was thinking that. Madison doesn't rearrange the replied-to accounts order. So i wrote that just in case but felt wrong doing so 😄