Constraints are the rules you attach to a table so the database itself refuses to store bad data. A PRIMARY KEY guarantees that every row can be uniquely identified (and that the key column is never empty), a FOREIGN KEY ties a column in one table to the key of another so relationships stay valid, NOT NULL forces a value to be supplied, UNIQUE blocks duplicate values in a column that is not the primary key, and DEFAULT supplies a value automatically when the INSERT statement leaves the column out. Together these are the backbone of relational integrity.
In this module you are learning Data Definition Language, and constraints are written directly into the CREATE TABLE statement alongside column names and data types. That makes them a design decision, not an afterthought: if you declare them correctly up front, the database enforces your business rules on every insert and update from then on. You will also see that constraints can be added, renamed, or dropped later with ALTER TABLE when requirements change.
As you watch the videos below, pay attention to the exact syntax and placement of each constraint (column-level versus table-level), to how a foreign key names the parent table and column it references, and to what the database actually does when a statement violates a rule. Note also that the examples come from CockroachDB, a PostgreSQL-compatible SQL database, so the ideas transfer directly but minor syntax details may vary from the DBMS you use in class.
A hands-on follow-up that walks through creating tables that include foreign key definitions in SQL. Expect to see CREATE TABLE statements in which a parent table is defined first and a child table then declares a column that REFERENCES it, illustrating referential integrity in practice.
It maps directly to the "Applying Constraints During Table Creation" subtopic by showing the constraint written inside a CREATE TABLE statement rather than discussed in the abstract.
A short conceptual explainer on what a foreign key constraint is, why it matters, and how it differs from a primary key. Based on its title and description, it covers the role of each key type in identifying rows and in linking a child table to a parent table, and explains the referential integrity the constraint protects.
Start here: it builds the vocabulary and mental model for the PRIMARY KEY and FOREIGN KEY subtopics before you write any syntax, and its large view count reflects a clear, widely used introduction from a SQL database vendor.
This video demonstrates the ADD CONSTRAINT clause, along with dropping and renaming constraints, using worked SQL examples. It shows how a constraint can be attached to a table that already exists instead of only at creation time.
It rounds out the topic by showing that constraints are maintainable objects, connecting constraint rules to the ALTER TABLE work covered elsewhere in this module.
These videos concentrate on the constraint-focused outcomes of the module. The conceptual foreign key video and the table-creation walkthrough support MO2 and MO3 by showing how PRIMARY KEY and FOREIGN KEY declarations are embedded in a CREATE TABLE statement to enforce integrity, and they model the same column-level syntax pattern you will reuse for NOT NULL, UNIQUE, and DEFAULT. The ADD CONSTRAINT video supports MO4 by demonstrating how constraints are added, renamed, or removed on an existing table without rebuilding it. Because every example is a DDL statement that defines or alters structure rather than querying or changing rows, the set also reinforces MO1; you should supplement them with your course readings for NOT NULL, UNIQUE, and DEFAULT practice and for the DROP, TRUNCATE, and DELETE comparison in MO5.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.