Permit applications must guarantee each application_id is unique and that every application references a valid parcel_id in the parcels table. Which constraints should be applied?
Select an answer to reveal the explanation.
Short Explanation
PRIMARY KEY is the city’s one-and-only permit ticket number; FOREIGN KEY is the rule that says you cannot hang a permit on a parcel that does not exist. Together they keep the permitting schema from inventing orphan applications.
Full Explanation
Permit applications need two complementary integrity rules: each application must be uniquely identified, and every application must reference a real parcel. A PRIMARY KEY on application_id enforces uniqueness and non-null identity for the application row. A FOREIGN KEY from applications.parcel_id to parcels.parcel_id enforces referential integrity so orphan applications cannot claim parcels that do not exist in the municipal parcels table. A DEFAULT plus a NOT NULL CHECK on parcel_id does not prove the parcel exists in parcels, and a DEFAULT on application_id is not a substitute for a primary key uniqueness guarantee across concurrent inserts. A UNIQUE constraint only on parcel_id wrongly forces at most one application per parcel and still fails to uniquely key applications if application_id can duplicate. A SEQUENCE may generate numbers but does not by itself declare primary or foreign key relationships on the applications table. Caveat: foreign keys require matching data types and a referenced unique/primary key on parcels; cascading rules must be chosen deliberately so parcel corrections do not unexpectedly delete applications. Operational check: attempt to insert an application with a duplicate application_id and another with a nonexistent parcel_id; both should fail, while a valid unique application referencing an existing parcel should succeed.