ECS is less about access patterns (relationships and queries) and more about efficient storage. Games care about page faults still so making your tight loop execute quickly on many smaller pieces of data and "do the right thing" is a win. Also, from an architectural perspective it's easier to write abstract code like `Health.value -= 10` instead of PlayerHealth.value -= 10`. By coding against a single components interface you can get consistent behavior across all entities with that component. You could also do this with inheritance but that becomes complex and (the real killer) very slow. jblow has some rants about this in the witness.
I don't think the entities/system are really that relational. Data is not denormalized in the same way and joins don't really exist. Indices are an after thought. Full sequential scans are the main access pattern.
But, it's easy to think of data for a component system as a table where each row is associated with an entity so I can see why you draw the similarity.
I don't think there is a fundamental difference. ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing. Sparse sets work well in this context, but they are ultimately an implementation detail. There are other ECS implementations that don't make use of it but can still deal with large throughput.
chrsig|4 years ago
They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
gravypod|4 years ago
jayd16|4 years ago
But, it's easy to think of data for a component system as a table where each row is associated with an entity so I can see why you draw the similarity.
looki|4 years ago