Types of Databases

Not every database stores data the same way. A live-score feed, a fan's shopping cart, a "who played with whom" network and a 10-year ball-by-ball archive each have different needs, so different types of databases exist. SQL is the language of one family — relational databases — which is the focus of this course.

Definition

A relational database stores data in tables (relations) made of rows and columns, and links tables to each other using keys. It is queried with SQL.

A NoSQL database ("not only SQL") is any database that does not use the table-of-rows-and-columns model. It stores data as documents, key-value pairs, graphs or wide columns, usually to gain flexibility or massive scale.

The five main types

Type	How data is stored	Popular products	Best for (IPL example)
Relational (SQL)	Tables with rows & columns, linked by keys	SQL Server, MySQL, PostgreSQL, Oracle	Players, teams, matches, ticket orders — structured data with relationships
Document	JSON-like documents	MongoDB, CouchDB	A fan profile with a flexible list of favourite players and badges
Key-Value	A key points to a value	Redis, Amazon DynamoDB	Live score cache: key match_45 → value "RCB 182/4 (18.2)"
Graph	Nodes and relationships (edges)	Neo4j	"Which players have played in the same team as Dhoni?"
Column-based	Stores data column by column	Apache Cassandra, Amazon Redshift	Analytics over billions of ball-by-ball records

Relational — the focus of this course

In a relational database, the players table and the teams table are linked through the team column:

players.name	players.team
Virat Kohli	RCB
Rohit Sharma	MI

teams.team	teams.team_name	teams.city
RCB	Royal Challengers Bengaluru	Bengaluru
MI	Mumbai Indians	Mumbai

Because both tables share the value RCB, SQL can join them and tell you that Virat Kohli plays in Bengaluru. Relational databases are strong at:

• Consistency — strict data types and rules (a run count can't be the word "hello").
• Relationships — combine many tables with JOINs (Chapter 6).
• Transactions — a ticket booking either fully happens or fully doesn't (ACID).

NoSQL in one line each

• Document — each record is a self-contained JSON document; different documents can have different fields.
• Key-Value — the simplest model; super-fast lookups by key, used for caching and sessions.
• Graph — perfect when the connections between things matter more than the things themselves.
• Column-based — reading one column across billions of rows is very fast, which suits analytics.

Note: "Column-based" is used for two related ideas: wide-column stores like Cassandra (NoSQL) and columnar data warehouses like Redshift or Snowflake (which still use SQL!). Many modern analytics tools speak SQL even when the storage is not a classic row-based table.

Common mistakes

• ❌ "NoSQL means no SQL at all." ✅ It means "not only SQL"; several NoSQL and big-data tools offer SQL-like query languages.
• ❌ "NoSQL is newer, so it is better." ✅ Each type solves a different problem. Most companies use a relational database as their main system of record.

Interview tip

Q: When would you choose a relational database over MongoDB? A: When the data is structured, has clear relationships (players ↔ teams ↔ matches) and needs strong consistency and transactions (payments, bookings). A document store fits better when each record's shape varies a lot and you rarely need to join across collections.

-- players.team holds codes like 'RCB'
SELECT name, team
FROM players;

-- teams.team holds the same codes, plus full names and cities
SELECT team, team_name, city
FROM teams;

-- Because both tables share the team code, SQL can combine them
SELECT p.name, t.team_name, t.city
FROM players AS p
JOIN teams AS t
    ON p.team = t.team;

-- 🏏 Your turn: which team codes appear in teams but have NO players? Compare the two results.
SELECT DISTINCT team
FROM players;

SELECT team
FROM teams;