A junior data engineer objects to denormalizing the object-catalogue reporting table, arguing that duplicating branch names and conservation-status text across millions of rows wastes storage and risks inconsistency if a branch is ever renamed. A senior engineer defends the design anyway. What is the strongest justification for choosing denormalization here despite that trade-off?
Select an answer to reveal the explanation.
Short Explanation
Think of it like keeping a duplicate set of keys at the front desk instead of walking back to the safe every single time: yes, now there are two sets of keys to keep track of, but the constant back-and-forth trip disappears. That trade is worth it when the trip happens far more often than the keys change.
Full Explanation
The core trade-off with denormalization is intentional: accepting redundant, duplicated fields and the storage they cost in exchange for read queries that no longer need to perform repeated joins, which is a strong win specifically for read-heavy, dashboard-style workloads where the same joins would otherwise run over and over. That's the justification the senior engineer should be making, not that denormalization is mandatory. Fabric doesn't require denormalized tables in a Lakehouse — normalized, joined designs are equally valid and often preferable for write-heavy or storage-sensitive scenarios, so denormalization is a deliberate choice, not a platform constraint. Denormalization has no bearing on access controls at all; row-, column-, object-, and file-level permissions apply independently of how the schema is shaped. And denormalized tables are typically larger, not smaller, than their normalized sources precisely because of the duplicated columns the junior engineer correctly flagged — the win is in read speed, not storage footprint. Before shipping the denormalized table, document the rename-propagation process for fields like branch name, since that operational cost is the real, ongoing price of this design choice.