Why should you care?

Without FKs, a Swiggy order_line could reference restaurant_id=999 when that restaurant was deleted, breaking settlement reports.

See it live — copy this example

Run in pgAdmin or psql.

CREATE TABLE customers (
  customer_id bigserial PRIMARY KEY,
  email text UNIQUE NOT NULL
);
CREATE TABLE orders (
  order_id bigserial PRIMARY KEY,
  customer_id bigint NOT NULL REFERENCES customers(customer_id)
);

What happened?

• customers is the parent; orders.customer_id must match an existing customer_id.
• PostgreSQL blocks orphan orders.
• You can later add ON DELETE RESTRICT or CASCADE depending on business rules.

Practice next

1. Create customers and orders in PostgresVerse.
2. Insert a customer, then an order referencing that id.
3. Attempt an order with customer_id=0 and read the FK violation.
4. Add order_items referencing orders with ON DELETE CASCADE.
5. Draw the FK graph with pgAdmin ERD after three related tables exist.

Remember

FK enforces parent-child integrity at the database. Choose DELETE actions deliberately per table. Normalize; do not repeat parent columns unnecessarily.

PostgresVerse CRM links

Support searches orders by customer email via JOIN instead of stale copied fields.

Outcome: Email change propagates automatically because orders only store customer_id.