Tables, Rows, Columns & Primary Keys

Every answer you get from SQL comes out of a table. Before writing real queries you must be able to look at a table and name each part correctly — column, row, cell, primary key — because these words appear in every chapter, every error message and every interview.

Definition — Table

A table is a database object that stores data about one kind of thing (an entity) in a grid of columns and rows. In relational theory a table is called a relation.

The players table stores data about IPL players — only players, nothing else. Teams have their own table, innings have their own table.

Definitions — Column, Row, Cell

A column (also called a field or attribute) is a vertical set of values that all describe the same property, and all have the same data type.

A row (also called a record or tuple) is one horizontal entry that describes one single item — here, one player.

A cell is the single value where one row and one column meet.

The table above has 5 columns and 6 rows. Columns are decided when the table is designed (structure); rows are added and removed all the time (data).

Definition — Primary Key

A primary key (PK) is a column (or a set of columns) whose value uniquely identifies every row in a table. It must be unique and can never be NULL (empty).

In players, the id column is the primary key: 1, 2, 3 … each number belongs to exactly one player.

Why not use name as the key? Because names can repeat (there could be two "Rahul Sharma"s), names can change spelling, and text keys are slower to compare. A small, meaningless number such as id never needs to change — that is called a surrogate key.

Rules of a primary key:

1. Unique — no two rows can share a key value.
2. Not NULL — every row must have a key value.
3. One per table — a table can have only one primary key (but it can span several columns — a composite key).
4. Stable — the value should never change once assigned.

Example — find one row by its primary key

SELECT *
FROM players
WHERE id = 3;

How it works: because id is unique, asking for id = 3 is guaranteed to return at most one row. That is exactly why apps use primary keys to fetch "this one player".

What happens if a duplicate key is inserted?

INSERT INTO players (id, name, team, country, runs)
VALUES (1, 'Shubman Gill', 'GT', 'India', 890);

SQL Server rejects it with an error like "Violation of PRIMARY KEY constraint … Cannot insert duplicate key in object 'dbo.players'. The duplicate key value is (1)." The DBMS protects your data automatically.

Foreign key (preview)

The team column in players holds values like RCB that also exist as the primary key of the teams table. A column that points to another table's primary key is called a foreign key — it is the "link" that makes a database relational. You will use it with JOINs in Chapter 6.

Common mistakes

• ❌ Calling a row a "column" or vice versa. ✅ Columns go down (properties), rows go across (items).
• ❌ Using name or email as a primary key "because it's unique today". ✅ Prefer a stable numeric id.
• ❌ Thinking rows are stored in a fixed order. ✅ A table has no guaranteed row order; use ORDER BY when order matters.

Interview tip

Q: What is the difference between a primary key and a unique key? A: Both enforce uniqueness. A primary key cannot contain NULL and there can be only one per table. A unique key (UNIQUE constraint) allows one NULL in SQL Server, and a table can have many of them.