From the article:<p><i>In general, when building a data model for end users you're going to want to materialize as much as possible. This often means denormalizing as much as possible so that, instead of having a star schema where joins are performed on the fly, you have a few really wide tables (many many columns) with all of the relevant information for a given object available.</i><p>Where "materialization" means whether a relation is created as a view (rather than a table).<p>I'm not sure I agree with this. Personally, I think it's better to primarily normalize and write all queries as close to functional programming as possible. Which means opting for computation on the fly during development and relying on the underlying database infrastructure to optimize internally. Then denormalize or dupe data via views and caching after bottlenecks have been identified. Otherwise you're fighting premature optimization during development.<p>That said, there could be a place for materialization in log-structured storage (LSS):<p><a href="https://jvns.ca/blog/2017/06/11/log-structured-storage/" rel="nofollow">https://jvns.ca/blog/2017/06/11/log-structured-storage/</a><p>I'm thinking that the future of all of this could be LSS on distributed consensus algorithms like RAFT, then devoting some amount of cache to building out materialized relationships that can always be derived from the log. Then we could have our cake and eat it too with fast durable writes and low-overhead reads without joins.<p>If anyone has an example of this, I'd love to see it.
> IDs should get an _id suffix, and primary keys should be called $OBJECT_id (e.g., order_id, user_id, subscription_id, order_item_name_id).<p>Wrong. Be consistent. All id's are named ID or id. Consistency is key.<p>Most of the article is filler and style choices.