On Friday, October 28, 2016 at 4:58:34 PM UTC-5, Rupert Smith wrote: > > On Friday, October 28, 2016 at 6:26:46 PM UTC+1, Kasey Speakman wrote: >> >> As best I can, I try to look at the system as use cases and events. >> >> With legacy systems, we are tied to a normalized data model (which is >> really designed for writing and not reading), so for queries we have to >> "project" from that normalized data model into another model. >> > > My understanding of normalization is that its purpose is to avoid > duplicating data, and by avoiding duplication reduce the chance of errors > in order to help ensure the quality of stored data. >
Yes, these are benefits of normalization. However, normalization optimizes for writing. Reads become more expensive due to joining in all the relevant details you need to service a particular query. In most business systems, multiple reads are performed for every write performed. It's a minor point for most business systems I've been a part of. However, I do currently have a couple of views where the reads became too expensive and it was better to maintain a denormalized read model alongside the normalized version. You might recognize this as a periodically-run report. But when I use events internally, I can have the report be updated cheaply as each event occurs rather than projected expensively from the normalized form. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
