A water utility meter-reading table must reject negative reading_value entries and values outside the sensor’s valid range. Which constraint should enforce that rule?
Select an answer to reveal the explanation.
Short Explanation
CHECK constraints are the water department’s “these numbers have to make sense” gate—no negative gallons, no fantasy spikes past the sensor max. Uniqueness or primary keys on the reading value would fight legitimate repeatable measurements.
Full Explanation
Water utility meter readings must stay within physically plausible bounds: negative values and out-of-range sensor readings indicate bad telemetry or entry errors. A CHECK constraint encodes those predicates declaratively so any INSERT or UPDATE that violates the non-negative and sensor-range rules fails immediately, protecting downstream billing and leak-detection analytics without relying solely on application code. UNIQUE on reading_value is wrong because many meters can legitimately report the same consumption number; uniqueness would reject valid civic data. A PRIMARY KEY on reading_value mistakes a measured quantity for an event identifier and collapses distinct reading events that share a value. External tables do not automatically relocate invalid readings; they expose external data and are not a substitute for domain CHECK logic on the operational meter table. Caveat: keep CHECK predicates aligned with sensor specifications and units; overly tight ranges will reject legitimate high-flow events, while overly loose ranges fail to catch obvious faults. Operational check: attempt inserts with a negative reading and with a value above the documented sensor maximum; both should fail the CHECK, while a mid-range reading should commit.