I found previous SE questions like this.
I'm familiar with the typical RDBMS backed MVC web app framework. To illustrate what I am thinking of, let's use the examples of Bunny and Carrot from this [article].
In a typical MVC
For a typical MVC RDBMS, you would have two tables. A
carrots table and a
bunnies table. Which is each associated with a Carrot model class and a Bunny model class.
What if we do this in a ECS way?
What would the database schema look like if we do it in ECS way?
Here's my speculation.
First, we would have each component become separate tables.
so we would have the following tables:
placeableswith the fields x, y, z
huggableswith the fields fluffiness
seeingswith the fields sight_radius, night_vision
livingswith the fields health, age
physicalswith the fields height, width, length
consumableswith the fields calories
hoppingswith the fields hop_distance
And in all these tables they will have an
entity_id as foreign key.
There will also be a
So Bunny is an Entity Type which means it's represented as a row inside
Same as Carrot.
A specific Bunny will be an actual entity with the id 1 and entity_type_id as foreign key in the
What we typically do of establishing the fields of a Bunny in a MVC way would be to put the fields inside the
Here we simply have a relation table
entity_type_to_component_types where the Entity Type Bunny is related to the specific Component Types
Now let's talk about the specific CRUD action
All the read operations will be join heavy.
They will involve joining all the individual component tables referencing the entity_id.
CUD are pretty straight forward and in fact might be better.
Relations between entities?
Typically a relation between entities in the MVC is simply a relation table.
Here, we can simply establish a specific relation as another component, say One Bunny eats Many Carrots then the component is
carrot_eaten_by_bunny which contains the specific carrot, and the specific bunny ids
My question is: is this implementation sound? What drawbacks do I not anticipate?
Is it just the huge number of joins when doing reads? How about creating virtual tables or views if reading speed is the issue?
Are there actually implementations like this in the real world I'm not aware of?