Если вы кодер, и база данных для вас - не что иное, как прославленное хранилище объектов, тогда, конечно же, во что бы то ни стало вводите суррогатные ключи. На самом деле, сделайте это лучше и просто делегируйте всю схему БД и взаимодействие с БД своему любимому ORM и покончите с этим. В самом деле, когда я хочу магазин объектов малого или среднего масштаба, это именно то, что я делаю.
Если вы сталкиваетесь с проблемой информационных систем или управления информацией, то это совсем другая история. Когда вы начинаете иметь дело с десятками (или, более вероятно, сотнями) миллионов грязных записей, интегрированных из нескольких источников, несколько или все из которых не находятся под вашим контролем; в этот момент соблазнительная приманка простого ответа на проблемы «идентичности» становится ловушкой.
Да, иногда вы все еще вводите суррогатный ключ внутри, чтобы обеспечить краткие отношения FK и повышенную эффективность кэширования при покрытии индексов; но вы получаете эти преимущества за счет существенной боли при управлении отношениями естественный ключ / суррогатный ключ.
В этом случае важно убедиться, что вы не допустите утечки суррогатного ключа. Ваш публичный API на уровне бизнес-логики должен использовать естественный ключ, ничто над документом / кэшем записей не должно знать о существовании суррогатного ключа. Имейте в виду, что стоимость сопоставления обновлений с существующими суррогатными ключами может быть непомерно высокой, а масштабируемость значительно больше, чем дополнительная стоимость перемещения нескольких дополнительных байтов на запрос по внутренней сети.
Итак, в заключение:
Если БД используется только как хранилище объектов: пусть ORM беспокоится об идентичности объекта, и почти наверняка должен быть суррогатный ключ.
Если БД используется в качестве базы данных: введение суррогатного ключа является решением технического проектирования с серьезными компромиссами в обоих направлениях. Решение должно приниматься в каждом конкретном случае с полным признанием результирующих затрат, которые должны быть приняты в обмен на выгоды, полученные в любом случае.
Обновление
«Удобство» суррогатного ключа - это просто способность разбираться в вопросе идентичности. Это часто необходимо в базе данных и разумно на уровне кэширования, насколько я позволю, но помимо этого это приводит к хрупкому дизайну данных. Проблема в том, что личность - это не то, что имеет один правильный ответ. Для нетривиальных систем с интенсивным использованием данных вам, как правило, придется работать в терминах классов эквивалентности , а не в качестве эталонного идентификатора, объектно-ориентированное программирование заставляет нас думать, что normal .
Что на самом деле сводится к осознанию того, что вся концепция «первичного ключа» - это выдумка, изобретенная для того, чтобы помочь реляционной модели работать эффективно; но принятие суррогатного ключа цементирует эту выдумку и делает всю систему хрупкой и негибкой. Бизнес-логика должна быть в состоянии предоставить свои собственные определения равенства - иногда четыре копии одного и того же файла должны рассматриваться как четыре файла , иногда они должны считаться неотличимыми от оригинала файл ; когда вы редактируете один из них, это новый файл ? тот же файл ? Ответ на оба вопроса, конечно, да, когда ... Работа с естественными ключами обеспечивает эту критическую способность работать в терминах концептуальных классов эквивалентности. Если вы позволите суррогатным ключам заражать вашу бизнес-логику, вы быстро потеряете это.