RDBMS Architecture
Overview
A Relational Database Management System (RDBMS) stores data in highly structured, rigidly defined tables (like Excel spreadsheets on steroids). These tables are 'relational' because they logically link to one another using Keys (e.g., a user_id in the Orders table links back to the Users table). This architecture strictly enforces data integrity, guarantees transactional safety (ACID properties), and completely eliminates duplicate data (Normalization).
Syntax
-- A visual representation of Relational Tables:
-- Table 1: Users (The Parent)
| id (PK) | username | email |
|---------|-----------|-----------------|
| 1 | Alice | alice@mail.com |
| 2 | Bob | bob@mail.com |
-- Table 2: Orders (The Child)
| order_id | amount | user_id (FK) |
|----------|--------|--------------|
| 101 | $50.00 | 1 | <-- Belongs to Alice
| 102 | $20.00 | 1 | <-- Belongs to Alice
| 103 | $99.00 | 2 | <-- Belongs to BobCommon Pitfalls
- Assuming NoSQL (MongoDB, DynamoDB) is strictly better than RDBMS (PostgreSQL, MySQL). NoSQL is great for unstructured, rapidly changing document data. However, if your data has strict relationships (like a financial app where Users have Accounts, and Accounts have Transactions), an RDBMS is overwhelmingly the superior architectural choice.
- Storing massive binary files (like high-res images or videos) directly inside a relational table as BLOBs. This destroys database performance and balloons backup sizes. Always store media in an object storage bucket (like AWS S3) and only store the URL string in the database.
Interview Questions
It refers to the mathematical concept of a 'Relation' (a set of tuples), which in practice means data is stored in tabular format (rows and columns) where different tables can be logically linked together using Primary and Foreign keys to prevent data redundancy.
Real-World Example
Why normalization is critical. If we didn't use relations, changing Alice's email would require updating thousands of rows.
-- BAD (Non-Relational / Flat File approach)
-- If Alice changes her email, we have to find and update 10,000 order rows!
| order_id | amount | username | email (DUPLICATED!) |
|----------|--------|----------|---------------------|
| 101 | $50 | Alice | old@mail.com |
| 102 | $20 | Alice | old@mail.com |
-- GOOD (Relational approach)
-- We just update Table 1 (Users). Table 2 (Orders) just points to User ID 1,
-- so it automatically references the new email via a JOIN.Check Your Knowledge
Test your understanding of RDBMS Architecture with these quick questions.