When to denormalize: signs your normalized schema is causing problems
Lars Singh
·369 views
our main transactional database schema is highly normalized, which made a lot of sense initially for data integrity. however, we're now finding that common read paths often require joining 7 or more tables, which can be slow and puts a lot of load on the database. caching helps, but then cache invalidation becomes incredibly complex because a change in any of those 7 tables means potentially invalidating multiple cached objects.
i'm starting to think about selective denormalization for these read-heavy paths. what are the clearest signals that indicate your normalized schema is causing more problems than it solves for a particular query or domain? how do you approach denormalization while trying to maintain some level of consistency, perhaps through materialized views, event streams, or specific service boundaries? i want to avoid the pitfalls of unchecked denormalization that leads to data inconsistencies.
0 comments