Data Modeling easy
Why might a developer intentionally 'Denormalize' a database (introduce redundancy)?
- A To significantly improve read throughput and reduce latency by avoiding computationally expensive JOIN operations across multiple tables.
- B To optimize the physical storage footprint of the database by consolidating multiple sparsely populated rows into a single compressed block.
- C To enforce a higher degree of ACID compliance by ensuring that related data items are physically co-located within the same transaction log.
- D To simplify the process of exporting raw data to third-party flat-file formats like CSV or XML for archival and long-term storage purposes.
Answer: A. To significantly improve read throughput and reduce latency by avoiding computationally expensive JOIN operations across multiple tables.
Denormalization is a deliberate strategy used to optimize read-heavy systems. By duplicating data (e.g., storing a 'Username' directly in a 'Comments' table), you eliminate the need for the database engine to perform a JOIN at query time. This provides O(1) access to pre-calculated views of the data, but introduces the complexity of maintaining consistency across all duplicate copies whenever a value is updated.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- When modeling a Distributed Transaction using the Saga Pattern (Choreography or Orchestration), what type of consistency do you achieve?
- Which practice prevents SQL Injection attacks?
- What is 'Bi-Temporal' data modeling (e.g., in SQL:2011 standard)?
- Adding an Index to a database column generally improves Read performance. What is the negative trade-off?
- Log Systems Merge (LSM) Trees (used in RocksDB, Cassandra) optimize for fast writes. What is their primary downside regarding Disk I/O?
- What is the primary objective of normalizing a relational database schema (e.g., to 3NF)?