A water utility exposes meter identity through an updatable view, but meter swaps must be validated before base tables change. Which object should enforce that rule?
Select an answer to reveal the explanation.
Short Explanation
INSTEAD OF on a view is the bouncer at the door: the swap request never walks straight into the base tables until the rules check out. Plain indexes and JSON columns do not intercept the write path.
Full Explanation
When a water utility exposes meter identity through an updatable view but meter swaps must be validated before base tables change, the write path has to be intercepted, not merely observed. An INSTEAD OF trigger on the view replaces the default view update with custom logic: validate that the old meter is eligible for swap, that the new meter is in inventory and not already assigned, then perform the coordinated writes to the underlying service and asset tables. Until that validation succeeds, nothing lands in the base tables—exactly what a regulated meter inventory requires.
An AFTER INSERT trigger on an unrelated ledger table that only fires for grant disbursements never sees meter-swap statements against the view and cannot enforce swap rules. A filtered nonclustered index on inactive meter_id values may help find inactive meters quickly, but indexes do not validate or redirect DML. A JSON computed column that stores a swap reason documents intent at best; it does not block invalid writes or orchestrate multi-table swaps.
Exam caveat: INSTEAD OF triggers are the standard mechanism for making complex views safely updatable; AFTER triggers run after the base write and are too late if the view’s default update path is incomplete or dangerous. Operational check: attempt a swap through the view with an ineligible meter, confirm the trigger raises an error and base tables are unchanged, then retry with a valid pair and verify both asset and service rows update as designed.