3 ms·

Using the relational model for app data in memory is really interesting. Martin Fowler wrote about doing that as a way to get around the "object-relational mis

Using the relational model for app data in memory is really interesting. Martin Fowler wrote about doing that as a way to get around the "object-relational mismatch" issue[1]. Richard Fabian describes "data-oriented design" as having a lot of overlap with the relational model[2]. ECSes becoming very popular in game engines are basically in-memory relational databases where "components" are "tables"[3]. [1]: https://martinfowler.com/bliki/OrmHate.html https://martinfowler.com/bliki/OrmHate.html [2]: https://dataorienteddesign.com/dodbook/ https://dataorienteddesign.com/dodbook/ [3]: https://github.com/SanderMertens/ecs-faq#what-is-ecs https://github.com/SanderMertens/ecs-faq#what-is-ecs

sitkack 4y ago
I'd love to see something like Relic able to operate over capnproto/arrow/parquet/avro/hdf5 etc along with a DAG based recomputation engine.
nextaccountic 4y ago
> "components" are "tables" No, components are columns. Each entity is a row in a table and an archetype (the set of all entities with the same components) is a table. In ECS it's usual to store components together, this corresponds to columnar storage in database terms (or equivalently, it's as if data were in sixth normal form [0]). However in some systems you can opt to store a more traditional row-based column. [0] https://en.wikipedia.org/wiki/Database_normalization#Satisfying_6NF https://en.wikipedia.org/wiki/Database_normalization#Satisfy...
- crabmusket 4y ago
  Thanks for the correction. In equating components and tables I was thinking of archetype-based engines, but even in that case they may store a whole set of components together in a single "table", right? Conceptually I think you could equate components with relations. For example a "grid location" component could be imagined as a relation with "entity ID" and "coordinate" columns. I suppose that admits multiple component instances per entity ID though which is typically not what you want.
- posterboy 4y ago
  > #Satisfying_6NF 6th Normal Form? I was taught that 3NF should be enough for all intents and purposes, which now sounds like the quote about 640k memory.
- dgb23 4y ago
  I assume with “components are columns” we don’t mean strictly single value columns. Small structs/aggregates could be quite common (like {from to} or {x y})?
  - erichocean 4y ago
    Yes
grumpyprole 4y ago
This idea was raised years before Martin Fowler blogged about it. The tar pit paper linked in the article is from 2006 and the author's had been doing this year's prior to that.

sitkack 4y ago

I'd love to see something like Relic able to operate over capnproto/arrow/parquet/avro/hdf5 etc along with a DAG based recomputation engine.

nextaccountic 4y ago

> "components" are "tables" No, components are columns. Each entity is a row in a table and an archetype (the set of all entities with the same components) is a table. In ECS it's usual to store components together, this corresponds to columnar storage in database terms (or equivalently, it's as if data were in sixth normal form [0]). However in some systems you can opt to store a more traditional row-based column. [0] https://en.wikipedia.org/wiki/Database_normalization#Satisfying_6NF https://en.wikipedia.org/wiki/Database_normalization#Satisfy...

crabmusket 4y ago
Thanks for the correction. In equating components and tables I was thinking of archetype-based engines, but even in that case they may store a whole set of components together in a single "table", right? Conceptually I think you could equate components with relations. For example a "grid location" component could be imagined as a relation with "entity ID" and "coordinate" columns. I suppose that admits multiple component instances per entity ID though which is typically not what you want.
posterboy 4y ago
> #Satisfying_6NF 6th Normal Form? I was taught that 3NF should be enough for all intents and purposes, which now sounds like the quote about 640k memory.
dgb23 4y ago
I assume with “components are columns” we don’t mean strictly single value columns. Small structs/aggregates could be quite common (like {from to} or {x y})?
- erichocean 4y ago
  Yes

grumpyprole 4y ago

This idea was raised years before Martin Fowler blogged about it. The tar pit paper linked in the article is from 2006 and the author's had been doing this year's prior to that.