ECS is a hodge-podge of concepts, each implementation mixing in different proportions some or all of the following: relational data model, data-oriented architecture, flexible recombination at runtime, removing the fixed inheritance graph, cache-friendly flow.
What's in the article is really closer to "relational data model" than all of these above. All these dictionaries are essentially implementing SQL selects. The "relational data model" lens to viewing ECS is that it's essentially giving each component its own table, and doing plenty of joins.
I find this really interesting, and my current side project is a roguelike game that focuses only on that part - relegating all game ECS into an in-memory SQLite database. I decided to go that way after trying to improve my last attempt at an ECS framework, only to realize I'm essentially hand-coding SQL indexes, and that's not something I want to do when I'm prototyping a game.
What's in the article is really closer to "relational data model" than all of these above. All these dictionaries are essentially implementing SQL selects. The "relational data model" lens to viewing ECS is that it's essentially giving each component its own table, and doing plenty of joins.
I find this really interesting, and my current side project is a roguelike game that focuses only on that part - relegating all game ECS into an in-memory SQLite database. I decided to go that way after trying to improve my last attempt at an ECS framework, only to realize I'm essentially hand-coding SQL indexes, and that's not something I want to do when I'm prototyping a game.