I'm half-way through the video, and he's pushing the Entity Attribute Value (EAV) model. He's right. He's absolutely right. There is a duality between the mu

I'm half-way through the video, and he's pushing the Entity Attribute Value (EAV) model. He's right. He's absolutely right. There is a duality between the much-hated EAV and table-oriented representations of data, especially if you are disciplined in your schema design so that the mapping between your EAV schema and a SQL table-oriented schema is natural. I really would like to see automatic duality between EAV and relational models in RDBMSes. This would give users great query expressive power. EAV is perfect for "graph" queries, which are essentially recursive queries that chase relations without having to specify which relation types -- as long as all of them have the same shape, you can do this with EAV. That means that you can write queries like "give me all the things this user has access to", or "all the users that have access to this entity" while traversing arbitrary relations like "user belongs to group", "group belongs to group", "access grant", etc. EAV is, essentially, the most normal form you can construct. And the more normal the form, the easier it is to apply CRDT techniques should you want to. Also, if you normalize the keys (see SQLite4[0], yes, 4, an abandoned project, but the docs are still there) then you get to trivially use any distributed ordered key/value store, and you can distribute the key ranges, and it's trivial. Now, EAV is much hated. But that hatred is wrong. The problem is that RDBMSes aren't exposing a dual of EAV and tables. If you have an EAV schema you can create VIEWs that look like equivalent table-oriented schemas -- the reverse is also possible, but somewhat harder. Using VIEWs to bridge the gap imposes a heavy burden on the query optimizer. But SQLite4 and similar database designs essentially have EAV stores internally that they could expose with a lot less complexity than VIEWs impose. We can haz EAV and table orientation at the same time. We should have it. Plus, as TFA says, you can combine EAV with timeseries, which allows you to have time travel in your queries, and even transactions (e.g., run a transaction now that has an effect in the future), which makes your data naturally copy-on-write, which greatly improves read performance. Granted, you have to cleanup unnecessary history at some point, otherwise it piles up (vacuum), but that's OK. [0] https://www.sqlite.org/src4/doc/trunk/www/design.wiki https://www.sqlite.org/src4/doc/trunk/www/design.wiki