Welcome to the World of Databases!
In our previous lessons, we looked at how data is organized into tables and normalized to reduce redundancy. But did you know that the "traditional" way of storing data (SQL) isn't always the best tool for the job? In this chapter, we will explore the tug-of-war between SQL (Relational) and NoSQL (Non-Relational) database systems. We'll learn why we need both and how to choose the right one for a real-world problem.
1. A Quick Refresher: SQL and Relational Databases
As you've learned in the "Relational Databases" chapter, SQL databases organize data into tables, records (rows), and fields (columns). They use primary keys and foreign keys to link data together.
Key characteristic: SQL databases have a fixed schema. This means you must define exactly what your data looks like (columns and data types) before you can add any information. It’s like a pre-printed form—you can’t just add a new box halfway through filling it out!
2. The Shortcomings of SQL
If SQL is so organized, why do we need anything else? Well, SQL has a few "weak spots" when dealing with modern, massive-scale applications like Facebook or Shopee:
A. Rigid Schemas: If you want to add a new type of information (e.g., adding a "TikTok Handle" field to a user table with 10 million rows), the database might have to go offline while it updates the structure. This is a nightmare for apps that need to stay online 24/7.
B. Scaling Difficulties: SQL databases usually scale vertically. To handle more data, you need a bigger, more expensive server (more RAM, better CPU). There is a physical limit to how "big" one server can get.
C. Performance with Unstructured Data: SQL is great for structured data (like numbers and names), but it struggles with "messy" data like social media posts, images, or sensor logs that don't fit neatly into a table.
3. Enter NoSQL: The Flexible Alternative
NoSQL stands for "Not Only SQL." Unlike relational databases, NoSQL systems do not use a fixed table-and-row structure. Instead, they can store data in different formats, such as documents (like JSON), key-value pairs, or graphs.
How NoSQL addresses SQL's shortcomings:
• Flexible Schema: In a NoSQL database, one record can have 5 fields, and the next record can have 10 fields. You don’t need to define everything upfront. This is perfect for agile development where features change fast.
• Horizontal Scaling: Instead of buying one giant server, NoSQL allows you to scale horizontally. You can simply add more cheap, standard servers to a "cluster." The database spreads the work across all \( N \) servers automatically.
• High Speed: Because NoSQL often avoids complex "JOIN" operations (which are mathematically expensive), it can read and write data much faster for specific tasks.
4. Key Comparison: Scaling
This is a common exam topic, so let’s use an analogy to make it stick!
Vertical Scaling (SQL): Think of this as buying a taller and taller skyscraper to house more people. Eventually, the building gets too heavy or the elevators become too slow.
Horizontal Scaling (NoSQL): Think of this as building a row of small houses. If you need more room, you just build another house next door. This is much easier to manage at a massive scale (\( n \to \infty \)).
5. Applications: Which one should I use?
Don't worry if you're confused about which one is "better"—neither is! They are just different tools for different jobs.
When to use SQL:
• Financial Systems: When you need 100% accuracy and consistency (e.g., a bank transfer).
• Structured Data: When the data is predictable and fits perfectly into tables.
• Complex Queries: When you need to pull data from 10 different sources and find complex relationships using Inner Joins.
When to use NoSQL:
• Big Data & Real-time Analytics: When you are processing millions of likes, views, or sensor readings per second.
• Content Management: For blogs or profiles where every entry might have different details.
• Social Media: Where the priority is speed and the ability to handle unpredictable "unstructured" content.
6. Working with Databases (Exam Perspective)
Depending on your examination year, your focus will be slightly different:
For 2026 Candidates: You are expected to have practical experience with both. You will use SQLite for SQL work and MongoDB (via the PyMongo library) for NoSQL work. You must know how to insert, update, and find data in both systems.
For 2027 Candidates: The focus has shifted. You only need to perform practical work with SQL (SQLite). For NoSQL, you only need to understand the concepts, how it solves SQL’s problems, and its applications. You will not be tested on MongoDB coding in Paper 2.
Quick Review: Key Takeaways
• SQL: Relational, fixed schema, scales vertically, best for structured/consistent data.
• NoSQL: Non-relational, flexible schema, scales horizontally, best for big data and rapid changes.
• Data Redundancy: SQL uses normalization (3NF) to reduce it; NoSQL often allows some redundancy to gain speed (denormalization).
• Remember: Use SQL for precision and NoSQL for scale and flexibility.
Common Mistake to Avoid: Many students think NoSQL is "better" because it's newer. That’s not true! A bank would never use a standard NoSQL database for account balances because accuracy (consistency) is more important than speed. Always choose based on the context of the problem!