Parks reservation rows should start as Pending until staff confirm the booking. Which constraint best supplies that initial status automatically?
Select an answer to reveal the explanation.
Short Explanation
DEFAULT is the parks desk’s sticky note that says “if nobody picked a status, call it Pending.” Staff can confirm later; the row does not arrive blank or force every insert to type the same literal by hand.
Full Explanation
Parks reservations commonly begin in a Pending state until staff confirm availability or payment. A DEFAULT constraint on the status column supplies Pending automatically when an INSERT omits the column, ensuring new municipal booking rows start in the correct workflow state without requiring every client application to remember the literal. Defaults are the standard declarative mechanism for this “initial value” pattern. A FOREIGN KEY to another database’s audit log does not set an initial status and introduces brittle cross-database coupling. A UNIQUE constraint that allows only one Pending reservation citywide would block ordinary concurrent bookings across parks. Ledger hashing addresses tamper evidence; it is not how you assign a default workflow status on insert. Caveat: DEFAULT applies when the column is omitted (or DEFAULT is specified); an explicit NULL or wrong status from the app still needs NOT NULL and/or CHECK rules if Pending must be mandatory for new rows. Operational check: INSERT a reservation row without specifying status and confirm the stored value is Pending; then INSERT with an explicit Confirmed status and confirm the default does not overwrite the supplied value.