Column constraints (NOT NULL, UNIQUE, CHECK) in PostgreSQL - Time & Space Complexity
When we add column constraints like NOT NULL, UNIQUE, or CHECK, the database must verify these rules for each row.
We want to understand how the time to insert or update data changes as the table grows.
Analyze the time complexity of inserting a row with constraints.
INSERT INTO users (email, age) VALUES ('user@example.com', 25);
-- email has UNIQUE constraint (creates B-tree index automatically)
-- age has CHECK (age >= 18)
-- email and age are NOT NULL
This code inserts a new user while the database checks constraints on the data.
Look at what the database does repeatedly when inserting rows.
- Primary operation: Checking the UNIQUE constraint requires an index lookup on existing emails.
- How many times: This lookup happens once per insert using the B-tree index.
As the table grows, checking constraints takes more effort.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 3 index comparisons for UNIQUE |
| 100 | About 7 index comparisons for UNIQUE |
| 1000 | About 10 index comparisons for UNIQUE |
Pattern observation: The UNIQUE check grows logarithmically with the number of rows.
Time Complexity: O(log n)
This means the time to insert grows logarithmically with the number of rows in the table.
[X] Wrong: "Checking UNIQUE constraints is instant no matter the table size."
[OK] Correct: The database must perform an index lookup to ensure uniqueness, which takes more time as the table grows.
Understanding how constraints affect performance helps you design better databases and write efficient queries.
"What are the time complexities of the NOT NULL and CHECK constraints?"
Practice
Solution
Step 1: Understand the NOT NULL constraint
NOT NULL means the column must always have a value; it cannot be left empty.Step 2: Compare with other constraints
UNIQUE prevents duplicates but allows NULLs; CHECK enforces custom rules; PRIMARY KEY implies NOT NULL and UNIQUE but is more specific.Final Answer:
NOT NULL -> Option BQuick Check:
NOT NULL = no empty values [OK]
- Confusing UNIQUE with NOT NULL
- Thinking CHECK prevents NULLs
- Assuming PRIMARY KEY is the only way to disallow NULL
email in a table users?Solution
Step 1: Recall the syntax for adding UNIQUE constraint
The correct syntax is: ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE (column_name);Step 2: Match the syntax with options
ALTER TABLE users ADD CONSTRAINT unique_email UNIQUE (email); matches the correct syntax exactly, naming the constraint and specifying the column.Final Answer:
ALTER TABLE users ADD CONSTRAINT unique_email UNIQUE (email); -> Option AQuick Check:
ADD CONSTRAINT name UNIQUE (column) [OK]
- Omitting CONSTRAINT keyword
- Placing UNIQUE before CONSTRAINT name incorrectly
- Not specifying column in parentheses
CREATE TABLE products (
id SERIAL PRIMARY KEY,
price NUMERIC CHECK (price > 0),
sku TEXT UNIQUE
);
What happens if you try to insert
price = -5 and sku = 'A123'?Solution
Step 1: Analyze the CHECK constraint on price
The CHECK constraint requires price > 0, so negative values like -5 violate this rule.Step 2: Consider the UNIQUE constraint on sku
Since 'A123' is new, UNIQUE is not violated here.Final Answer:
Insert fails due to CHECK constraint violation on price -> Option CQuick Check:
CHECK (price > 0) rejects negative price [OK]
- Ignoring CHECK constraint effects
- Confusing UNIQUE violation with CHECK violation
- Assuming negative numbers are allowed
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
email TEXT UNIQUE NOT NULL,
age INT CHECK (age >= 18)
);
Which statement will cause an error when inserting data?
Solution
Step 1: Check NOT NULL constraint on email
Email cannot be NULL because of NOT NULL constraint.Step 2: Check CHECK constraint on age
Age must be 18 or older; the ages in A(25), B(20), and D(18) all satisfy this.Final Answer:
INSERT with NULL email causes error due to NOT NULL constraint -> Option DQuick Check:
NOT NULL rejects NULL email [OK]
- Focusing on CHECK constraint instead of NOT NULL
- Ignoring NOT NULL on email
- Assuming UNIQUE causes error on first insert
orders where the quantity column must be a positive integer and the order_code must be unique and never empty. Which is the best column definition for quantity and order_code?Solution
Step 1: Ensure quantity is positive integer
CHECK (quantity > 0) enforces positive values only, better than >= 0 which allows zero.Step 2: Ensure order_code is unique and not empty
UNIQUE prevents duplicates; NOT NULL disallows empty; this combination ensures order_code is unique and present.Final Answer:
quantity INT CHECK (quantity > 0), order_code TEXT UNIQUE NOT NULL -> Option AQuick Check:
CHECK positive + UNIQUE NOT NULL = correct constraints [OK]
- Allowing zero quantity
- Missing NOT NULL on unique column
- Using CHECK without NOT NULL for order_code
Ready to prove it?
Pass the test and this pattern moves unknown
