The county assessor wants every application to format parcel APN strings the same way without copying formatting logic into each app. Which object should centralize that formatting?
Select an answer to reveal the explanation.
Short Explanation
Park the APN makeup rules in one scalar function—like a shared stamp pad—so every app presses the same format. Triggers and indexes are the wrong toolbox for display formatting.
Full Explanation
The county assessor’s requirement that every application format parcel APN strings the same way is a classic centralization problem for a pure computation: input an APN (or its parts), output a canonical display string. A scalar user-defined function holds that formatting logic once so permitting, tax, and GIS apps all call the same function in SELECT lists, computed columns, or procedures—eliminating copy-pasted mask logic that drifts over time.
An AFTER UPDATE trigger that formats APNs only when tax rates change couples formatting to the wrong event and still leaves read paths and other apps without a shared formatter. A columnstore index may compress string dictionaries for analytics; compression is not display formatting and does not guarantee a consistent APN mask in applications. A partition scheme that splits data by the first digit of a parcel map is a storage placement choice, not a string-formatting API.
Exam caveat: keep formatting functions deterministic and side-effect free; do not hide UPDATEs inside scalar UDFs. Operational check: pass the same raw APN through the scalar function from two different calling modules and assert identical output strings, then change the function’s mask once and confirm both callers pick up the new format without code edits.