Если выполнить SQL-запрос:
- SELECT id FROM <таблица>
то весьма вероятно он не только выполнится без ошибок, но и вернёт множество (в самом хорошем, математическом, смысле этого слова) целых чисел.
Многие программисты, с которыми я знаком, добавляют во все создаваемые таблицы столбец с автоматически генерируемыми монотонно возрастающими целыми числами и делают его первичным ключом. Однако, когда я спрашиваю, зачем это нужно, я редко получаю разумные аргументы в ответ. Большинство отвечает просто «все так делают» или «просто привыкли». Как вы знаете, привычки бывают полезными и вредными. В этой записи я постараюсь показать, что привычка добавлять автоинкрементный столбец и делать его первичным ключом может быть весьма вредной.
Давайте вспомним, зачем вообще нужны первичные ключи. Распространённая, хоть и неправильная, точка зрения состоит в том, что первичный ключ позволяет однозначно идентифицировать строку в таблице. Это неправильное понимание причины и следствия. На самом деле первичные ключи необходимы для гарантированного отсутствия повторяющихся строк.
Когда требование отсутствия повторяющихся строк уже выполнено, можно утверждать, что первичный ключ однозначно определяет конкретную строку в таблице. Если мы рассмотрим это более строго, то можно сказать, что как сам первичный ключ целиком, так и подмножество столбцов первичного ключа (в случае составного ключа), и даже столбцы, не входящие в первичный ключ (что часто наблюдается, когда программисты бездумно создают суррогатные ключи), могут однозначно указывать на конкретную строку. Все это зависит от того, как спроектирована таблица.
Однако, давайте вернемся к основной цели нашего разговора. Мы уже установили, что первичный ключ необходим для гарантии отсутствия повторяющихся строк и является способом «усиления семантики». Добавляя столбец с гарантированно уникальным значением, вы не вносите ничего нового с точки зрения данных, а лишь создаете иллюзию хорошо спроектированной таблицы. В действительности, вы можете создать любое количество записей, которые будут идентичны во всех столбцах, кроме столбца с суррогатным ключом. Я не буду описывать проблемы, к которым это может привести, так как уверен, что вы сами понимаете, почему такие таблицы являются очень плохой идеей.
На этом этапе многие могут возразить, утверждая, что использование «естественного» составного первичного ключа и передача его из родительской таблицы в дочернюю является плохой идеей. Это разумное замечание. Я сам являюсь не только теоретиком, а также практиком, и поэтому в таких ситуациях рекомендую использовать суррогатный ключ с обязательным наложением ограничения уникальности на потенциальный ключ. Таким образом, мы одновременно защищаемся от появления семантически идентичных строк в таблице и получаем возможность передавать в процедуры, запросы и дочерние таблицы короткое целочисленное значение. Кроме того, стоит помнить, что чем короче ключ, тем более эффективно работают ограничения FOREIGN KEY и операции соединения, а также требуется меньше места для хранения ключа в связанных таблицах.
Безусловно, существуют и другие ситуации, когда суррогатные ключи необходимы. Например, в организациях часто используются табельные номера сотрудников, что является идеальным примером для применения автоинкрементных уникальных значений. На самом деле, каждый из вас сможет придумать множество ситуаций, когда использование суррогатных ключей оправдано. Однако, прошу вас не применять их бездумно в каждой таблице! И если вам все же необходимы суррогатные ключи, то стоит задуматься, не будет ли лучшим решением использование GUID-ов вместо автоинкрементных значений.