Кто может сказать, каждая ли таблица должна содержать primary key?
В чем его особая роль?
Где почитать?…

Обе утверждения истинны:

1. Таблица не обязана содержать первичный ключ.
2. Правильно спроектированная реляционная БД не должна содержать таблиц, не имеющих первичного ключа.

Обоснование есть у Дейта. Ну и у Кодда, разумеется. Цитировать здесь не буду, поскольку оно предполагает понимание концепции "реляционная БД". Впрочем, оно также хорошо раскрыто у Дейта. Ну и у Кодда, разумеется.

Что бы точно знать, что каждая строка в таблице уникальна - нужен первичный ключ. Первичные ключи делят на натуральные и суррогатные.

Натуральный первичный ключ:

Допустим таблица заказов состоит из 3-х столбиков:
В данной таблице 1 и 2 столбики вместе составляют Первичный Ключ.
Потому что они делают каждую запись (строчку) уникальной.

Докажем это:

Строка:
будет уникальной, потому что клиент не должен иметь возможность сделать два заказа одновременно (в ту же секунду).

Одного времени (столбик 1) не достаточно что бы определить уникальность строки. Нужен еще стоблик 2.
Потому что два разных клиента могут заказать товар одновременно:

Что бы найти конкретную строку, вам надо знать по крайней мере: дату и номер клиента.
Если вы знаете только дату (или только клиента) - вы рискуете получить несколько строк.
Вместе: Дата и Номер клиента - это первичный ключ.

---------------------------------------------------------
Суррогатный первичный ключ:

Не всегда удобно иметь первичный ключ состоящий из 2-х и более столбиков.
Потому что не всегда удобно искать строку по значениям 2-х и более столбиков.

Поэтому искусственно добавляют еще один столбик (например Номер заказа):
Здесь "Номер заказа" автоматически генерируется для каждого заказа (каждое число на единицу больше чем предыдущее.)

Теперь что бы найти конкретную строку - достаточно знать только "Номер заказа".

Это называется суррогатный первичный ключ. Потому что мы искусственно добавили столбик, что бы обеспечить уникальность строки.
Натуральный первичный ключ - это когда хватает самих данных что бы обеспечить уникальность строки.
--------------------------------------------------

Когда вы указываете что такой то столбик (или столбики) должен быть первичным ключем - вы задаете правило, которое база данных будет соблюдать:
- данные в столбике будут уникальны (если ключ - это один столбик)
- совокупность данных в столбиках будут уникальны (если ключ - это два и более столбиков)

И такие ошибочные ситуации возникнуть не должны:
(неясно что клиент заказал: книгу или ручку?)

Или:
(Какой заказ истинный?)

Если задать первичный ключ - такие ситуации не возникнут.
Потому что база данных выкинет ошибку.

Если не указать первичный ключ - база не будет выкидывать ошибок и будет молча принимать все, что в нее пишут. А вы потом будете иметь головную боль разбирая данные.


-------------
"Натуральный первичный ключ", правильнее называть: "Естественный первичный ключ"
это на английском - Natural Primary Key

ну нифига себе, сколько всего надо знать, чтобы заказать простую ручку!

AlexShop, все это замечательно, но:

1. Упущено понятие "потенциальный ключ".
2. То, что "Дата и время" и "Номер клиента" являются потенциальным ключом -- по меньшей мере не очевидно. Тяжесть фразы "не должен иметь два заказа в одну секунду" вы осознаете, когда однажды случится делать миграцию данных или интеграцию с другой системой (с другим сайтом).
3. Суррогатные включи вводят вовсе не потому, что неудобно искать по нескольким полям. Хотя в этом тоже помогает. Но только как следствие.

Кроме того, фраза пр головную боль может быть полностью раскрыта только если объяснить, что такое нормальные формы (хотя бы первые 2) и как они связаны с использованием первичных ключей.

Так что лучше, как я уже говорил, взять Дейта. Первых глав достаточно, его вообще редко дочитывают до конца.

А наличие или отсутствие первичных ключей сказывается на производительности базы данных?
Если у меня, предположим, нет первичного ключа, но есть индексы, таблицы будут с той же скоростью объединяться?

И еще вопрос... Надо ли создавать индексы на колонках, которые участвуют в условиях поиска (where) в виде "and column_name = 1"? Т.е. колонка не участвует в объединении талиц, а только определяет условия выборки.

1. Обычно при добавлении primary key формируется индекс.
2. При правильно спроектированной базе индексы помогают строить объединение. При неправильно спроектированной -- не помогают.
3. Индексы на колонках, участвующих в условиях where, строят в зависимости от селективности значений. Если там 10,000 записей и в них только значения 1, 2 и 3, то от индекса не будет никакой пользы кроме вреда.

Crazy,
спасибо за критику.
Дейта не читал. Но обязательно прочту.

При миграцию данных (в моем примере), да есть проблемы:
- если другая таблица заказов не будет иметь "Дата и время" (а другой первичный ключ).
- часы на разных серверах почти всегда не синхронизированы, поэтому "Дата и время" могут пересекаться.
- так как "Дата и время" является частью первичного ключа - изменять ее вручную (в случае чего) очень не желательно.

Потому что если я изменю первичный ключ, это значит его придется менять на всех резервных, дублирующих устройствах и архивах (что бы сохранить целостность данных).

Что бы иметь возможность свободно менять "Дата и время" - это еще один повод, что бы использовать суррогатный ключ в моем примере.
Но аргументов за и против использования того или иного ключа действительно много.

Это не "еще один повод", а основная причина.