Engineering

The History of "Ownership" vs "Belonging": From RDB to ECS

PUBLISHED
  • Architecture
  • ECS
  • RDB
  • OOP
  • History
  • Game Development

When I first started thinking about state management in games, I assumed the “belonging” paradigm — where entities register with central data stores — was something new. But as I dug into the history, I discovered that this idea appears to go back to the 1970s.

I found this journey fascinating, so I wanted to share what I learned.

1970s: The Relational Model and “Belonging”

Edgar F. Codd’s Relational Model (1970)

In June 1970, Edgar F. Codd published “A Relational Model of Data for Large Shared Data Banks” in Communications of the ACM. Reading about this paper, I learned it introduced what we now call relational databases.

-- Entities "belong" to tables as rows
SELECT health FROM enemies WHERE id = 123;

The relational worldview:

  • Data exists in central tables
  • Entities are referenced by IDs
  • State is an “entry” in a table, not a “property” of an object

This is the “belonging” paradigm.

Why Did RDB Choose “Belonging”?

  • Data consistency through normalization
  • Query efficiency through indexing
  • Concurrent access through transactions

Central aggregation appears to have offered fundamental advantages.

1980s: OOP and the Return to “Ownership”

The Rise of Smalltalk and C++

From what I’ve read, object-oriented programming gained prominence in the 1980s:

  • Smalltalk-80 was released publicly in 1980
  • C++ was renamed from “C with Classes” in 1983, with commercial release in 1985
class Enemy {
    int health;  // The object "owns" its state
public:
    void takeDamage(int damage) {
        health -= damage;
    }
};

The OOP worldview:

  • Objects encapsulate data and behavior
  • Each instance owns its state
  • Communication through message passing

This is the “ownership” paradigm.

Why Did OOP Choose “Ownership”?

  • Real-world modeling (“an enemy has health”)
  • Information hiding through encapsulation
  • Reusability through inheritance and polymorphism

It seems to align naturally with how we think about the world.

Impact on Game Development

Unity’s GameObject/MonoBehaviour model is a direct extension of OOP:

public class Enemy : MonoBehaviour {
    public int health;  // Each instance owns its state
}

2000s: Performance Problems and the Rise of ECS

The Limits of OOP

As I researched further, I found that as games grew larger, certain problems emerged:

  • Cache misses from scattered data
  • Memory fragmentation
  • Update overhead

The Birth of ECS

In my research, I found two works that seem to have been particularly influential in shaping the Entity Component System paradigm:

Scott Bilas at GDC 2002 presented “A Data-Driven Game Object System” based on his work on Dungeon Siege at Gas Powered Games. From what I’ve read, this is widely credited as one of the foundational ECS presentations.

Adam Martin in 2007 wrote “Entity Systems are the future of MMOG development,” a blog series that appears to have popularized ECS concepts and terminology.

Entity: Just an ID
Component: Data only (no behavior)
System: Processing logic

A return to “belonging.” Data exists in central component arrays, and entities are referenced by ID.

The Similarity to RDB

When I mapped out the concepts, the parallels were striking:

RDBECS
TableComponent Array
RowEntity
Primary KeyEntity ID
SELECTQuery

It almost feels like ECS could be described as “RDB for game development.”

2010s: ECS Proliferation and “All or Nothing”

Major Frameworks

  • 2014-2015: Entitas (C#) — created 2014, gained traction in 2015
  • 2017: EnTT (C++) — used in Minecraft Bedrock Edition
  • 2018: Unity DOTS
  • 2020: Bevy ECS (Rust)

The “All or Nothing” Message

From what I observed, the ECS community’s messaging was often:

“If you want data-oriented benefits, abandon GameObjects and migrate fully.”

This seems to have made many developers hesitate:

  • High learning curve
  • Existing code becomes obsolete
  • Workflow changes completely

What I Learned from This History

The Flow of Paradigms

1970: RDB — "Belonging" paradigm
      ↓
1980: OOP — Return to "Ownership" (matches human intuition)
      ↓
2000: ECS — Return to "Belonging" (driven by performance needs)

What Stood Out to Me

  • “Belonging” isn’t new — RDB established it in 1970
  • OOP’s “ownership” appears to feel intuitive to many — but seems to have performance limits at scale
  • ECS appears to be heading in the right direction — but “all or nothing” may have created adoption barriers

The Value of Hybrid Approaches

What I find interesting is the potential for middle ground — taking ECS insights (contiguous memory, change detection) while preserving existing workflows. Whether that’s the right tradeoff depends on your specific needs.

References