Playground Checkpoint
Design and build a real schema — no auto-grading, just a real attempt.
The Challenge
It's official: GreenMart is acquiring Riverside Grocers, a smaller rival across town. Mike is thrilled. Sarah is staring at Riverside's database export, and it looks nothing like GreenMart's own.
Different column names. Different tables. Some of Riverside's own rules are looser than GreenMart's — a customer with no name on file, one with no phone number. A few of Riverside's products, like Apples and Bread, are ones GreenMart already sells. Others aren't.
Nobody is going to tell you which chapter's idea to use here. Open the Playground, read both schemas carefully, and bring Riverside's real data into GreenMart's database — correctly, safely, and without losing or duplicating a single thing.
What Your Schema Needs
- Migrate every Riverside customer into GreenMart's Customers table, without letting any Riverside ID collide with a GreenMart ID that already exists.
- Handle the fact that Riverside's schema allows a missing customer name, which GreenMart's schema does not — every migrated customer must end up with a real, non-NULL name.
- Migrate Riverside's products, but do not create a duplicate for any product GreenMart already sells under the same name — only genuinely new products should become new rows.
- Migrate Riverside's orders and order line items, correctly pointing each one at the right final customer and the right final product — including the ones that got matched to an existing GreenMart product instead of a new row.
- Wrap the entire migration in a single transaction, so it either completes entirely or leaves GreenMart's database completely untouched.
- Confirm, with real counts, that nothing was lost and nothing was duplicated: GreenMart's customer, product, order, and order-item counts should each grow by exactly the right amount.
- In your own words (no SQL needed for this part): where would Riverside's staff fit into the roles-and-permissions plan from Act 6, and where would Riverside's data fit into GreenMart's city-sharding plan from the same Act?
Stuck? A Few Hints
- Two rows from two different databases can easily share the same ID by coincidence, even though they mean completely different things — decide on a way to shift one side's IDs before combining anything.
- A product should be matched by what it actually is, not by which database it came from — think about what makes two product rows "the same" product, and use that to decide whether Riverside's version needs a new row at all.
- A backfill has to happen before a NOT NULL rule can be trusted — this idea should feel familiar from a much earlier Act.
Ready to Build It?
Opens the Playground, right in your browser — nothing to install.
Before You Move On
This is what every chapter since Act 1 was actually building toward — not remembering syntax, but recognizing, in a completely unfamiliar schema, exactly which ideas from this course applied: keys that needed renumbering, a constraint that needed backfilling before it could be trusted, duplicate data that needed catching before it was created, and a transaction boundary that made the whole thing safe to attempt at all. GreenMart is a bigger, real company now — built the same careful way, one honest problem at a time, from the very first page of Mike's notebook to here.