Skip to course content
Free SQL course

SQL for Data Analysis and AI

Unit 10.04: Re-validating after the final small edit

Unit ID: SQL-M10-U05 - Estimated active time: 12-15 minutes Objective: treat any change to a validated query as invalidating the validation.

The last edit is the dangerous one

The failure pattern is consistent: build carefully, validate thoroughly, then make one small change just before sending - add a column, adjust a filter, rename something - and ship without re-checking.

That final edit arrives *after* the careful thinking has stopped, which is exactly why it is the one that breaks things.

Changes that look cosmetic and are not

Adding a column from another table turns a validated query into a join:

-- Validated: 988 rows
SELECT order_id, order_total FROM orders WHERE status = 'completed';

-- "Just adding the item count" - now at item grain, 3,364 rows
SELECT o.order_id, o.order_total, i.sku
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
WHERE o.status = 'completed';

Every aggregate downstream is now inflated. The edit looked like adding a field.

Widening a filter changes the population:

-- fragment: WHERE clause shown on its own
-- 988 orders, ₹26,85,905
WHERE status = 'completed'

-- 1,000 orders, ₹27,01,463 - a 0.58% change nobody announced
-- (filter removed)

Changing a date boundary by one day moves 33 orders (Module 8).

The re-validation is short

You do not repeat the whole process. Re-run the two checks that would catch a grain or population change:

-- Population unchanged?
SELECT COUNT(*) FROM orders WHERE status = 'completed';   -- 988

-- Total unchanged?
SELECT SUM(order_total) FROM orders WHERE status='completed';  -- 2685905.00

Thirty seconds. If both match what you validated, the edit was genuinely cosmetic.

Keep the check with the query

Leave the reconciliation query in the file beside the analysis, commented:

-- VALIDATION (expect 988 | 2685905.00)
-- SELECT COUNT(*), SUM(order_total) FROM orders WHERE status = 'completed';

Now the expected values travel with the query, and anyone editing it later - including you in three months - can confirm in one paste that they have not changed the answer.

Practice

You add ORDER BY order_total DESC LIMIT 100 to a validated revenue query before sending it. What re-check do you run, and what would you expect?

Check your answer

Re-run the total. You should expect it to be unchanged - but only if the LIMIT sits outside the aggregate. If the query was SELECT SUM(order_total) FROM (SELECT … LIMIT 100), the total now covers 100 orders instead of 988, which is Module 2's truncated-aggregate trap arriving through a late edit.

Check where the LIMIT actually applies, then confirm 988 | 2685905.00 still holds.

Takeaway

Any edit invalidates the validation. Re-run the population and total checks - thirty seconds - and keep the expected values in the file so the check survives you.

---