A primary key is the column — or combination of columns — that uniquely identifies every row in a table. Because no two rows may share the same primary key value, and because a primary key column cannot be left empty (NULL), the primary key is the database's guarantee that each record can be found, updated, or referenced without ambiguity. In SQL you declare this guarantee as a constraint, either while creating the table or later with an ALTER TABLE statement, and the database engine enforces it on every insert and update from that point forward.
Primary keys matter in this course for two reasons. First, they are the foundation of data integrity: without one, duplicate or near-duplicate rows creep in and queries return unreliable results. Second, they are the anchor point for relationships — a foreign key in one table points at the primary key of another, so every topic later in this module depends on understanding this one. Choosing a key well also has practical consequences for performance and for how painful future schema changes will be.
As you watch the videos below, pay attention to three things: the exact SQL syntax used to declare, add, and drop the constraint; what the database does when you try to insert a duplicate or NULL value; and the reasoning behind choosing one column (or set of columns) over another as the key. Note also that syntax and behavior differ slightly between database systems, so compare what you see against the system you are using in this course.
A short talk from Cockroach Labs on how to think about primary key design rather than just how to type the syntax. It covers the basics of what makes a good key and connects key choice to database performance, which is the practical argument behind most best-practice advice. Expect discussion of the tradeoffs involved in selecting key columns.
This video speaks directly to the "Why Primary Keys Matter" and "Best Practices for Choosing a Primary Key" subtopics, and comes from a database vendor's technical evangelist, so the design reasoning is grounded in real engine behavior.
A focused, step-by-step demonstration of adding a PRIMARY KEY constraint to a column in a table that already exists, using MySQL. It shows the ALTER TABLE syntax and walks through the operation on a live table rather than describing it abstractly. At just over four minutes, it is a direct how-to with little digression.
It maps exactly onto the "Adding a Primary Key to an Existing Table" subtopic and gives you the ALTER TABLE form you will need alongside the CREATE TABLE form.
The companion demonstration from the same channel, showing how to remove or drop an existing primary key constraint from a MySQL table. It walks through the statement used to drop the constraint and the effect on the table afterward. Watching this immediately after the previous video gives you both directions of the operation.
It covers the "Dropping a Primary Key Constraint" subtopic directly, and its consistent format and tooling with the previous video make the add/drop pair easy to compare and remember.
Together these videos concentrate on the constraint mechanics and design judgment at the heart of this topic. The MySQL add and drop demonstrations give you the ALTER TABLE syntax called for in MO2, complementing the CREATE TABLE form you will practice in the module readings and exercises. The CockroachDB design talk supports MO4 by framing primary key selection as a reasoned tradeoff rather than a default choice, and it reinforces MO1 by clarifying what distinguishes the primary key from other keys in a table. Use the module materials and labs to extend this foundation to foreign keys, candidate keys, and referential actions (MO3 and MO5), which these videos do not address.
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.