In this lesson, you will learn why keeping the same information in multiple places creates "data redundancy" and how this leads to dangerous errors and slower systems.
The Problem with Duplication
Imagine you are managing a library database. You decide to store the author’s name and phone number inside every single book record.
If an author writes 50 books, their phone number is stored 50 times. While this seems fine at first, it creates two major risks:
- Consistency Risks: If that author changes their phone number, you must hunt down all 50 records and update every single one. If you miss even one record, your database now contains conflicting information. This is called an update anomaly.
- Performance Costs: Every time you add a new book, you have to type out the author's contact details again. This wastes storage space and increases the chance of a "typo" entering your system.
A Concrete Illustration
Compare these two approaches to storing information about an author named "Alice":
The Redundant Way:
| Book_Title | Author_Name | Author_Phone |
|---|---|---|
| SQL Basics | Alice | 555-0101 |
| Advanced DB | Alice | 555-0101 |
If Alice updates her number to 555-9999, you have to perform two separate updates. If you accidentally update only the first row, your database is now "inconsistent"—it claims Alice has two different phone numbers.
The Non-Redundant Approach:
Instead of duplicating, we keep data in one place and reference it. You might have a table for Authors and a table for Books. The Books table would only hold the Author_ID.
By keeping each piece of information in exactly one spot, you ensure that there is only ever one "source of truth." When that truth changes, you update it in one location, and your entire database reflects that change instantly without the risk of conflicting records or wasted storage.
Key Takeaway: Data redundancy forces you to update information in multiple places to stay consistent, which is inefficient, wastes space, and invites dangerous data errors.