Syllabus Lesson 60 of 141 · Data models that bend
Data models that bend

Change requests you have not seen

Why it matters The first schema an assistant writes fits the request in front of it, exactly. Real data models live for years, and the expensive moment is the third request, not the first. A model that bends absorbs it in a few lines; a model that does not needs a migration.

Ask for "a bank account with a balance" and you get a number that goes up and down. It answers today's question perfectly. Then someone asks what the balance was last March, and the number cannot tell you: the history was thrown away the moment each deposit was added.

Change request: a new question asked of the same data, or a new fact about it, after the model is built.

Where change requests come from

  • Time: "what was it on a past date?", "what will it be next month?"
  • Cardinality: "a customer can have a second address", "an order can have two payers".
  • Identity: "people change their names", "two products share a name".
  • Corrections: "that entry was wrong: reverse it, but keep the record".

You cannot build for every future. You can ask which of these four the business is most likely to bring, and keep the facts those questions need instead of only the answer to today's.

In this module every problem says plainly what kind of change is coming. The hidden tests then ask those questions with data you have not seen. Each problem names the functions the change requests will call, so you can build them now.

Recap Keep the facts, not just today's answer. Time, cardinality, identity and corrections are where most models break.

Spotted a problem in this lesson? Report it · Ask about this lesson

This exercise opens soon

Finish the lesson before it and this one unlocks. The whole course is free, no account needed, and you can read this lesson right now.

Start at lesson 1 Back to syllabus