A county clerk cash window needs sequential receipt numbers for payments without relying on an identity column on every related table. Which object should they implement?
Select an answer to reveal the explanation.
Short Explanation
You can use a SEQUENCE as the clerk’s ticket dispenser: request the next receipt number, hand it to the payer, and keep the line moving. A filtered index, graph edge table, or columnstore index won’t generate that number for you.
Full Explanation
County clerk cash windows may need monotonically increasing receipt numbers on demand from multiple procedures or tables, rather than an IDENTITY property tied to one payments table. A SEQUENCE object generates numeric values independently of a single table, so you can share one database-controlled numbering series across related municipal payment processes, such as counter payments, mail payments, and online settlements. A filtered index can support query patterns or sort receipt text alphabetically after insertion, but it does not allocate receipt numbers. A graph edge table can model links between receipts and cashiers, but it is not a numeric generator. A columnstore index compresses data and accelerates analytical scans; it does not invent sequential receipt identifiers during compression. Exam caveat: SEQUENCE values can have gaps after rollbacks or failed transactions, so treat them as unique, ordered issuance numbers—not gapless proof of every attempted payment—unless the business process handles gaps explicitly. Review cache and increment settings so multiple clerk sessions do not serialize unnecessarily. Practical check: call NEXT VALUE FOR the receipt sequence from two sessions, confirm distinct increasing numbers, then use those values in payment inserts without requiring IDENTITY on every related table.