что выбрать для первичного ключа в таблице?

Question

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

• Должен ли я оставить свой естественный ключ также в качестве первичного ключа? или это должно быть точно так же, как любая другая колонка?

большинства доступа к этой таблице поиска по естественному ключу

• для выполнения времени, если естественный ключ быть удален или определен в качестве альтернативного ключа?
• Я не хочу иметь 2 идентичных натуральных ключа, как это следует применять, используя естественный ключ как первичный ключ?
• Что это значит, если я использую натуральный ключ в качестве первичного ключа, а также добавляю еще один суррогатный ключ и определяю его также как первичный ключ? Я попытался найти примеры, которые действительно могли бы найти хороший, ссылки и примеры действительно помогут.

Answer 1

Мое предложение заключается в создании простого INT типа данных первичного ключа и сделать его AUTO_INCREMENT, если вы используете MySQL, IDENTITY, если вы используете MS SQL Server или SEQUENCE, если вы используете Oracle. Тип данных INT для первичного ключа очень хорош, если вам нужна производительность.

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

Answer 2

Лучший способ сделать это - использовать уникальный ключ базы данных (такой как AUTO_INCREMENT в MySQL и его братьев и сестер в других СУБД) и создать объединенный первичный ключ, состоящий из этого и вашего естественного ключа.

Позвольте мне объяснить, почему:

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

Соединив ключ «база данных-естественный» с ключом «приложение-естественный» (в этой последовательности!) До комбинированного первичного ключа, вы получите лучшее из обоих миров. Это особенно верно, если естественный ключ состоит из некоторого случайного фактора, такого как GUID.