A city permits office is designing an Azure SQL table for parcel IDs, fee amounts, and inspection dates. Which column design best fits those municipal permit fields?
Select an answer to reveal the explanation.
Short Explanation
Think of parcel IDs like badge numbers that must fit a known format, fees like cash drawer totals that need exact cents, and inspection dates like calendar stamps—not free-form essays. Right-sized character, decimal, and date/datetime2 columns keep municipal permit rows honest without wasting space or inviting junk.
Full Explanation
Municipal permit schemas succeed when each column’s type matches the real domain of the attribute rather than a generic catch-all. Parcel identifiers are structured codes with a known format and length, so a fixed-width character type preserves the exact digits and separators agencies already print on notices and GIS layers. Fee amounts are money: they need exact scale and precision, which decimal (or a carefully planned numeric type with explicit scale) provides without floating-point drift during assessments, refunds, and reconciliations. Inspection events are calendar facts; date or datetime2 stores them so range filters, aging reports, and SLA clocks remain correct. Float identifiers destroy leading zeros and invite rounding artifacts, while nvarchar(max) for fees and varchar dates treat currency and calendars as free text—breaking sorting, indexing, and validation. sql_variant defers integrity to the application and blocks many constraints and predictable plans. Legacy image/text and unplanned money usage add storage and compatibility debt without improving municipal data quality. On DP-800-style design items, prefer domain-aligned types over “flexible” storage when the business already knows formats and scales. Caveat: datetime2 still needs a documented time zone or business-date convention for field inspectors who close cases after midnight. Operational check: after creating the table, insert a representative parcel ID with leading zeros, a fee with two decimal places, and a boundary inspection timestamp, then confirm SELECT returns identical values and that indexes on those columns remain sargable.