Production engineering
Reveal answer and reasoning
Define the business meaning of absence before choosing nullable storage, application defaults and report aggregates. A useful acceptance boundary names presence, numeric range and type requirements separately, then uses fresh persisted-state checks to verify rejection. Keep the portable helper as a small deterministic model and the SQL fixture as provider evidence. For a different database, repeat the actual semantic tests instead of transplanting SQLite conclusions.
When presenting a count or sum, include the population and NULL policy so another consumer can distinguish all records from known measurements and avoid interpreting missing information as zero without an explicit rule.
For a production import, specify how absent, explicit NULL, zero and malformed values map to domain results before designing the schema. Parameterized commands keep data separate from SQL syntax, but do not supply those meanings automatically. Add independent fixtures for each rejected category and compare fresh database state after the attempted write. Choose error translation at the boundary that knows whether a constraint failure is ordinary invalid data or an operational problem.
Keep diagnostics useful without dumping sensitive values, and document which provider/version produced the verified semantics.
What a strong answer covers
- WHERE retains true; NULL equality is unknown in the tested SQL contract.
- The fixed fixture has5 rows,2 NULL amounts and3 known amounts with sum6.
- CHECK-only NULL acceptance and NOT NULL rejection are independent actual SQLite checks.
Common pitfall
Assuming a positive-range CHECK also guarantees presence and a rigid integer type.
Follow-up questions
- What changes if every amount is NULL rather than zero?
- How would STRICT-table or type-affinity requirements be tested separately?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.