State normalization for relational data

WHAT THIS TESTS Whether you treat the Redux store like a relational database rather than a snapshot of the UI. It probes your understanding of duplication, update cost, and consistency in large, interconnected state.

A GOOD ANSWER COVERS Normalization means each entity type lives in its own lookup table keyed by id, with an accompanying array of ids for ordering. Relationships are expressed by storing foreign ids, not nested objects. This gives a single source of truth, so updating an owner touches one place instead of every item that embedded a copy; lookups and updates become direct id access; and components can select exactly the entities they need. It mirrors database design and pairs well with Redux Toolkit's createEntityAdapter, which generates normalized reducers and selectors.

COMMON WRONG ANSWERS Keeping deeply nested arrays for convenience, duplicating related data so edits go stale, or normalizing trivially small state where the overhead is not justified. Forgetting to also track ordering with an allIds array is a subtle gap.

LIKELY FOLLOW-UPS How does createEntityAdapter help? How do you re-denormalize for rendering, and where do you do that work? How do you handle many-to-many relationships?

ONE CONCRETE EXAMPLE Before: items is an array where each item embeds a full owner object, so owner Ada appears duplicated in three items. After: state.items.byId maps itemId to { id, title, ownerId }, state.items.allIds lists order, and state.users.byId maps userId to the single owner record. Renaming Ada updates one entry in users.byId, and every item referencing that ownerId reflects the change instantly with no duplication or stale copies.