Flying DutchmanWho am IВопрос с ходу: всегда ли нужен primary key?

Да.


В реляционной модели данных PK нужны, в противном случае будет невозможно применять теорию реляционных БД.

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

Короче, разделяйте теоретическую модель и техническую реализацию.

ОКТОГЕНОКТОГЕНeNose, ну если вам мало
18446744073709551616 строк в пределах одного сервера,
то я не знаю что и предложить.
Вы можете использовать тип NUMERIC без ограничений на точность.
В PostgreSQL таковой имеется.
Проверил, 510 значное число вполне себе сохраняется.

Да вы посчитайте, сколько времени уйдёт на вставку такого колиества записей. Полагаю вопрос про запас отпадёт сам собой.

Ещё добавлю...

Немаловажно время и сложность генерации ключа. Если целое число, это грубо говоря i++ (плюс блокировка разделяемого ресурса и время от времени сохранение в БД), то GUID вычисяется сложнее. Вероятная неуникальность в пределах одной БД разрешается на уровне PK - если с новым GUID PK нарушается, ну создаём новый GUID.

В оракле GUID широко используются для генерации Type ID и Object ID. Причём даже в распределённых БД я не слыхал о проблемах связанных с совпадением GUID во время репликации, но и в VLDB я бы их использовать не стал.

Расчитывать на использование всего множества значений MAC адресов или GUID не приходится. Часть значений либо остануться навсегда зарезервированными (как например коды производителей в MAC адресах), часть будет безвозвратно потеряна (если в алгоритме GUID используется время).

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

PK как правило используются для поиска записей и индексируются. Сравнение длинных ключей во время поска идёт чуток дольше. Индекс с длинным ключём занимает больше места в БД и в кэше.

Но всё это дело десятое .

Если реализация БД будет сильно отличаться от модели, расходы на её сопровождение быстро превысят экономию на дисках. Сейчас терабайтным диском или многотерабайтным RAID'ом в домашнем ПК мало кого удивишь.

Реляционная алгебра оперирует множествами, а множество это набор уникальных элементов. Если мы говорим о реляционном отношении, то подразумеваем, что у него есть PK. В противном случае это не отношение.
ER моделирование и тем более функциональная декомпозиция оперируют отношениями.

В объектных БД каждый объект идентифицируем и не обязан иметь PK.

Создавать PK в БД не обязательно.