arrow_backBack to Phase 2
database

Data
Modelling

How you structure your data determines how your system scales. Choosing the right schema is the most permanent decision you will make.

The Fundamental Choice

Before picking a database (MySQL, MongoDB, Neo4j), you must understand the structure of the data itself. Is it a Table, a Document, or a Graph?

1. Relational Modelling (SQL)

Best for structured data with strict schemas. Relies on Normalization to reduce redundancy.

Strengths

  • • ACID compliance for transactions.
  • • Powerful JOINS for complex queries.
  • • Mature tooling and ecosystems.

Weaknesses

  • • Rigid schema changes are painful.
  • • Hard to scale horizontally (sharding is complex).
  • • Performance hits on deep joins.

2. Document Modelling (NoSQL)

{ "user": "alice", "posts": [{ "id": 1, "text": "Hello world" }] }

Best for unpredictable or rapidly evolving schemas. Data that is read together should be stored together (denormalization).

"Use document models when your app scales by adding more machines rather than bigger ones."

3. Graph Modelling

account_tree

When the Relationships between the data are as important as the data itself.

  • • Social Networks (Followers of followers).
  • • Fraud Detection (Money trails).
  • • Recommendation Engines.

Relationships: 1:N vs N:N

One-to-Many (1:N)

Example: One User has many Posts. In SQL: Foreign Key. In NoSQL: Embedding or Reference.

Many-to-Many (N:N)

Example: Many Students in many Classes. Requires a **Join Table** in SQL or **Duplicate References** in NoSQL.

Interview Case: Twitter Modeling

"How would you store the 'Follow' relationship at scale?"

Option A: Relational

A `Followers` table with `follower_id` and `followee_id`. Simple, but slow for 'followers of followers' queries.

Option B: Graph DB

Nodes for Users and 'FOLLOWS' edges. Extremely fast for graph traversal, but harder to maintain than SQL.