Database Design That Actually Works - From Schema to SQL to Real Apps

By Chetan Sharma | February 21, 2024

Databases Aren't Boring - They're Actually Crucial

Introduction: When I Realized Databases Matter

I built my first project with a terrible database design. I just threw data everywhere without thinking: user names in one table, user posts in another, user settings scattered around. It worked fine at first.

Then I tried to find all posts by a user from a specific city. One query took 30 seconds. THIRTY SECONDS. For something that should be instant.

I rewrote the schema properly, normalized the data, added some indexes. Same query: 50 milliseconds.

That's when I got it. Database design isn't optional. It's not advanced wizardry. It's just... thinking about how your data connects before you build it. Get the schema right and everything else gets so much easier.

This guide is what I wish I'd known starting out. Practical database design stuff.

1. What is a Database Management System?

DBMS Definition and Purpose

A DBMS is software that enables users to define, create, maintain, and control access to databases. It acts as the interface between applications and actual data storage.

Core Responsibilities:

Data Definition - Create schema structure
Data Manipulation - Insert, update, delete, retrieve
Data Security - Control access, prevent unauthorized use
Data Integrity - Maintain consistency and validity
Concurrency Control - Handle multiple users simultaneously
Recovery - Protect against failures

File Systems vs Databases

Traditional File Systems:

Data scattered across multiple files
No relationships between files
Data redundancy (same data in multiple places)
Difficult to maintain consistency
No query language

Databases:

✓ Centralized data repository
✓ Relationships between entities
✓ Minimize redundancy (normalization)
✓ ACID guarantees
✓ Powerful query language (SQL)
✓ Access control
✓ Concurrent access support

2. Database Models

Relational Model (Most Prevalent)

Data organized into tables (relations) with:

Rows - Records/tuples
Columns - Attributes/fields
Relationships - Links between tables via foreign keys

Example: Student Management

Students Table:
┌─────┬──────────┬─────────────┐
│ ID  │ Name     │ Department  │
├─────┼──────────┼─────────────┤
│ 101 │ Raj      │ CSE         │
│ 102 │ Priya    │ ECE         │
└─────┴──────────┴─────────────┘

Courses Table:
┌─────┬────────────────┬─────┐
│ ID  │ Course Name    │ CID │
├─────┼────────────────┼─────┤
│ 201 │ Data Structures│ C1  │
│ 202 │ Database Design│ C2  │
└─────┴────────────────┴─────┘

Enrollment Table (Junction):
┌──────────┬─────────┐
│ Student  │ Course  │
├──────────┼─────────┤
│ 101      │ 201     │
│ 101      │ 202     │
│ 102      │ 201     │
└──────────┴─────────┘

Hierarchical Model

Data organized in tree structure with parent-child relationships.

Used in: File systems, XML databases
Limitation: Cannot represent many-to-many relationships

Network Model

Extension of hierarchical allowing multiple parents (graph structure).

Historical importance (CODASYL databases)
Superseded by relational model

Document/NoSQL Model

Data stored as JSON documents, key-value pairs, or column families.

Tools: MongoDB, CouchDB, Cassandra
Advantages: Flexible schema, scalable
Trade-offs: No ACID by default, schema-less complexity

3. ER Model and Database Design

Entity-Relationship Model

Entities: Objects of interest (Student, Course, Professor) Attributes: Properties of entities (Student.Name, Student.ID) Relationships: Associations between entities

Cardinality and Relationships

One-to-One (1:1)
One student:One student ID
Implementation: Foreign key on one side

One-to-Many (1:N)
One professor:Many courses
Implementation: Foreign key on "many" side

Many-to-Many (N:N)
Many students:Many courses
Implementation: Junction table

Zero or One (0..1)
Optional relationship
Implementation: Nullable foreign key

ER Diagram Example

STUDENT
├─ ID (PK)
├─ Name
├─ Email
└─ DepartmentID (FK)
        ↓
        1:N
        ↓
DEPARTMENT
├─ ID (PK)
├─ Name
└─ Location

4. Normalization - Eliminating Data Anomalies

Why Normalization Matters

Anomalies Without Normalization:

Student_Course Table (Denormalized):
┌─────┬────────┬──────────────────┬──────────────┐
│ SID │ Name   │ Course           │ Instructor   │
├─────┼────────┼──────────────────┼──────────────┤
│ 101 │ Raj    │ Data Structures  │ Prof. Singh  │
│ 101 │ Raj    │ Database Design  │ Prof. Verma  │
└─────┴────────┴──────────────────┴──────────────┘

Problem: Name "Raj" duplicated - redundancy
If Raj transfers departments, update multiple rows!

Normal Forms

First Normal Form (1NF)

Eliminate repeating groups
Atomic values only (no arrays/lists in cells)

Before:
┌─────┬────────┬─────────────────────────────┐
│ ID  │ Name   │ Courses                     │
├─────┼────────┼─────────────────────────────┤
│ 101 │ Raj    │ DS, DB, Algorithm           │
└─────┴────────┴─────────────────────────────┘

After (1NF):
┌─────┬────────┬──────────────┐
│ ID  │ Name   │ Course       │
├─────┼────────┼──────────────┤
│ 101 │ Raj    │ DS           │
│ 101 │ Raj    │ DB           │
│ 101 │ Raj    │ Algorithm    │
└─────┴────────┴──────────────┘

Second Normal Form (2NF)

Must be in 1NF
Remove partial dependencies
Non-key attributes depend on entire key

Third Normal Form (3NF)

Must be in 2NF
Remove transitive dependencies
Non-key attributes depend only on key (directly, not transitively)

Transitive Dependency Example:
Student → EnrollmentYear → SemesterFees
(Student determines enrollment year, which determines fees)

Solution: Separate into tables

Boyce-Codd Normal Form (BCNF)

Stricter than 3NF
Every determinant must be a candidate key

Denormalization Trade-offs

✓ Faster queries (fewer joins)
✗ Slower updates (redundant data)
✗ Consistency issues
✗ More disk space

When to denormalize:
- Read-heavy workloads
- Real-time analytics
- Denormalization is algorithmic, not data structure

5. SQL - Structured Query Language

Data Definition Language (DDL)

-- Create table
CREATE TABLE Students (
    StudentID INT PRIMARY KEY AUTO_INCREMENT,
    Name VARCHAR(100) NOT NULL,
    Email VARCHAR(100) UNIQUE,
    Department VARCHAR(50),
    EnrollmentDate DATE,
    GPA DECIMAL(3, 2),
    CONSTRAINT chk_gpa CHECK (GPA >= 0 AND GPA <= 4.0)
);

-- Modify table (add column)
ALTER TABLE Students ADD Phone VARCHAR(15);

-- Drop table
DROP TABLE Students;

Data Manipulation Language (DML)

-- Insert
INSERT INTO Students (Name, Email, Department, GPA)
VALUES ('Raj Kumar', 'raj@college.edu', 'CSE', 3.8);

-- Update
UPDATE Students 
SET GPA = 3.9, Department = 'IT'
WHERE StudentID = 101;

-- Delete
DELETE FROM Students 
WHERE StudentID = 101;

-- Select (most important)
SELECT * FROM Students;

Data Query Language (DQL) - SELECT Magic

Basic Select:

-- All columns
SELECT * FROM Students;

-- Specific columns
SELECT Name, Email, GPA FROM Students;

-- With conditions
SELECT Name, GPA FROM Students
WHERE Department = 'CSE' AND GPA > 3.5
ORDER BY GPA DESC;

Aggregation Functions:

SELECT 
    Department,
    COUNT(*) as StudentCount,
    AVG(GPA) as AverageGPA,
    MAX(GPA) as HighestGPA,
    MIN(GPA) as LowestGPA
FROM Students
GROUP BY Department
HAVING COUNT(*) > 5
ORDER BY AverageGPA DESC;

JOINs - Combining Tables:

-- INNER JOIN (matching records in both)
SELECT s.Name, e.CourseName
FROM Students s
INNER JOIN Enrollment e ON s.StudentID = e.StudentID;

-- LEFT JOIN (all left + matching right)
SELECT s.Name, e.CourseName
FROM Students s
LEFT JOIN Enrollment e ON s.StudentID = e.StudentID;

-- Multiple JOINs
SELECT 
    s.Name,
    c.CourseName,
    p.Name as ProfessorName
FROM Students s
INNER JOIN Enrollment e ON s.StudentID = e.StudentID
INNER JOIN Courses c ON e.CourseID = c.CourseID
INNER JOIN Professors p ON c.ProfessorID = p.ProfessorID;

Subqueries:

-- Find students with above-average GPA
SELECT Name, GPA
FROM Students
WHERE GPA > (SELECT AVG(GPA) FROM Students);

-- Correlating subquery
SELECT Name
FROM Students s
WHERE StudentID IN (
    SELECT StudentID FROM Enrollment 
    WHERE CourseID IN (
        SELECT CourseID FROM Courses 
        WHERE Department = s.Department
    )
);

6. ACID Properties - Data Integrity

The Four ACID Properties

Property	Meaning	Implementation
Atomicity	All or nothing - transaction fully completes or not at all	Rollback on failure
Consistency	Data stays valid before/after transaction	Constraints, triggers
Isolation	Concurrent transactions don't interfere	Locking mechanisms
Durability	Committed data survives failures	Write-ahead logging

Transaction Example

-- Transfer money between accounts
BEGIN TRANSACTION;

UPDATE Accounts SET Balance = Balance - 5000 WHERE AccountID = 101;
UPDATE Accounts SET Balance = Balance + 5000 WHERE AccountID = 102;

-- If error occurs, ROLLBACK entire transaction
-- Both updates happen or neither happens (Atomicity)
COMMIT;

7. Indexing - Query Performance

How Indexes Work

Without Index:
Query "SELECT * FROM Students WHERE Email = 'xyz@mail.com'"
→ Scan all 1 million rows (1 second)

With B-tree Index on Email:
→ Binary search through index tree (0.001 seconds)
→ Instant access to student record

Types of Indexes

B-tree Index (Most Common)

Self-balancing tree structure
Fast searching, insertion, deletion
Used for: Range queries, equality queries

Hash Index

Hash function maps key to bucket
Fast equality search: O(1)
Poor for: Range queries, sorting

Full-Text Index

For text searching
Used in: Search engines, full-text queries

Composite Index

Multiple columns: (LastName, FirstName)
Useful for common query patterns

Index Trade-offs

✓ Faster SELECT queries
✗ Slower INSERT, UPDATE, DELETE
✗ Extra disk space
✗ Maintenance overhead

When to index:
- Columns used in WHERE clauses
- Columns used in JOIN conditions
- Large tables with selective queries

Index Performance

-- Check query execution plan
EXPLAIN SELECT * FROM Students WHERE Email = 'raj@mail.com';

-- Create index
CREATE INDEX idx_email ON Students(Email);

-- Verify index usage
-- Query should now show "Using index" in EXPLAIN output

8. Query Optimization

Query Optimization Techniques

1. Use Specific Columns

-- Bad: Unnecessary data transfer
SELECT * FROM Students;

-- Good: Only needed columns
SELECT StudentID, Name, GPA FROM Students;

2. Minimize Joins

-- Slow: Multiple joins
SELECT s.Name FROM Students s
JOIN Enrollment e ON s.StudentID = e.StudentID
JOIN Courses c ON e.CourseID = c.CourseID;

-- Fast: Direct relationship if available
SELECT s.Name FROM Students s
WHERE EXISTS (SELECT 1 FROM Enrollment 
    WHERE StudentID = s.StudentID);

3. Use EXPLAIN to Analyze

EXPLAIN
SELECT s.Name, c.CourseName FROM Students s
INNER JOIN Enrollment e ON s.StudentID = e.StudentID
INNER JOIN Courses c ON e.CourseID = c.CourseID
WHERE s.GPA > 3.5;

-- Analyze returned execution plan:
-- - Which indexes used?
-- - Table scan or index? 
-- - Join order optimal?

4. Avoid Function Calls on Indexed Columns

-- Bad: SUBSTRING not indexed
SELECT * FROM Students 
WHERE SUBSTRING(Email, 1, 3) = 'raj';

-- Good: Direct comparison
SELECT * FROM Students 
WHERE Email LIKE 'raj%';

9. Transactions and Concurrency Control

Isolation Levels

Dirty Read:     Transaction reads uncommitted data from another
Non-Repeatable: Data changes between reads in same transaction
Phantom Read:   New rows match criteria during transaction

Isolation Levels (Strictness):
1. READ UNCOMMITTED (No protection)
2. READ COMMITTED (Avoid dirty reads)
3. REPEATABLE READ (Avoid dirty + non-repeatable)
4. SERIALIZABLE (Complete isolation)

Locking Mechanisms

Pessimistic Locking (Lock First)

BEGIN TRANSACTION;
SELECT * FROM Accounts WHERE AccountID = 101 FOR UPDATE;
UPDATE Accounts SET Balance = Balance - 5000 WHERE AccountID = 101;
COMMIT;

Optimistic Locking (Version Number)

UPDATE Accounts 
SET Balance = Balance - 5000, 
    Version = Version + 1
WHERE AccountID = 101 AND Version = 5;

-- If version mismatched, update fails (concurrent modification detected)

10. NoSQL vs Relational

When to Use Relational

✓ Structured data with relationships ✓ ACID requirements ✓ Complex queries ✓ Data integrity critical ✓ Examples: Financial systems, CRM

When to Use NoSQL

✓ Unstructured/semi-structured data ✓ Horizontal scaling needed ✓ High write throughput ✓ Flexible schema ✓ Examples: Social media, IoT devices, caching

NoSQL Types

Document Database (MongoDB, CouchDB)

{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "name": "Raj Kumar",
  "email": "raj@college.edu",
  "courses": ["DS", "DB", "Algorithm"],
  "enroll_date": ISODate("2024-01-15")
}

Key-Value Store (Redis, Memcached)

"student:101" → {"name": "Raj", "gpa": 3.8}
Perfect for: Caching, sessions, user preferences

Column-Family Store (Cassandra, HBase)

Row Key | Timestamp | StudentData
101     | 1234567   | name:Raj, gpa:3.8

Graph Database (Neo4j)

STUDENT[has_enrolled]→COURSE
STUDENT[follows]→STUDENT
COURSE[taught_by]→PROFESSOR

Real-World Database Scenarios

Scenario 1: Social Media Platform (Facebook Scale)

Requirements:

Billions of users and relationships
Real-time notifications
User feeds with personalization

Solution:

Primary database: SQL (user profiles, security)
Cache layer: Redis (feed, notifications)
Graph database: Neo4j (friend relationships)
Search: Elasticsearch (feed search)
Analytics: Cassandra (event data)

Scenario 2: E-commerce Platform (Amazon Scale)