Normalization gives you a rigorous, theory-backed way to eliminate redundancy and protect data integrity. But production systems rarely live at a single point on that scale. Real designs sit somewhere along a spectrum: some tables are kept in strict 3NF or BCNF because correctness and frequent updates demand it, while others carry precomputed totals, merged attributes, or summary rows because the read workload would otherwise be too slow or too expensive. Knowing where on that spectrum a given table belongs is a design skill, not a rule you memorize.
This topic matters in COP4708 because it connects everything you have practiced so far — functional dependencies, normal forms, ER-to-relational mapping — to the questions an engineer actually gets asked: How will this be queried? How often is it written? How large will it get? What breaks first when traffic grows tenfold? Denormalization is only defensible when you can name the workload pattern it serves and the cost you are accepting in write overhead, storage, or update anomalies. Without that reasoning, it is just a shortcut that creates bugs later.
The three videos below approach the problem from different angles: common design mistakes and how to avoid them, a structured way to choose the right data store for a workload, and the fundamental contrast between relational and NoSQL models. While watching, keep a running list of the decision criteria each speaker uses — read-vs-write ratio, data volume, consistency requirements, query shape, growth expectations. Those criteria are the raw material for the decision framework you will apply in this module, and they are also the basis for revisiting a design later when the workload changes.
Database Star walks through seven frequent database design errors and offers a corrective approach for each. Based on the title and channel focus, expect issues tied to table structure, redundant or poorly placed columns, key and relationship choices, and naming or data-type decisions that cause trouble as a schema grows. Each mistake is paired with a suggested fix rather than just a warning.
It grounds the normalization-versus-denormalization discussion in concrete, recognizable schema problems, which helps you distinguish accidental redundancy (a mistake) from deliberate redundancy (a strategic choice). Database Star is a long-running channel focused specifically on database design and SQL, so the framing is practitioner-oriented and directly relevant to the subtopics on when strict normalization is the right call.
ByteByteGo surveys the major categories of databases and the factors that push a system toward one option over another. Expect discussion of workload characteristics such as read and write patterns, data volume and growth, query types, and consistency requirements as inputs to the selection decision. The format is a compact, diagram-driven overview aimed at system design reasoning.
This is the closest match to the decision-framework, workload-alignment, and scalability subtopics, since it models the kind of structured reasoning you are asked to produce in MO5. ByteByteGo is a well-known system design channel whose explanations are concise and widely used as an industry reference point.
IBM Technology contrasts relational (SQL) databases with NoSQL alternatives, covering how each stores and structures data and the trade-offs that follow. Expect coverage of schema rigidity versus flexibility, how joins and normalized structures compare to document or key-value access patterns, and scaling considerations for each family. The presentation uses a whiteboard-style explanation suited to newcomers.
It extends the normalization spectrum beyond relational design, showing how some NoSQL models embrace denormalized, query-shaped storage by default — a useful contrast when judging whether redundancy is justified. The producer is a major enterprise vendor's technical education channel, and the explanation is clear and neutral enough to serve as a conceptual anchor.
Together these videos support the applied end of the module's outcomes. The design-mistakes video reinforces why normalized structures exist in the first place, supporting the classification and schema-translation work in MO1 and MO2 by showing what unmanaged redundancy actually costs. The database-selection and SQL-versus-NoSQL videos supply the vocabulary of workload profiles, read/write ratios, storage cost, and scaling behavior that you need to compare normalized and denormalized schemas (MO4) and to choose a specific denormalization technique for a stated performance scenario (MO3). Most directly, the structured selection reasoning in the ByteByteGo video models the kind of criteria-based justification MO5 asks you to produce, and all three reinforce the habit of revisiting a design as requirements and traffic change.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.