первичный ключ базы данных

Question

У меня есть пользовательская таблица с сотнями миллионов строк и полем username (varchar). Должен ли я сделать его первичным ключом вместо уникального индекса? Каковы преимущества или недостатки добавления дополнительного поля user_id (int) и превращения его в первичный ключ? Я не вижу, где бы я использовал user_id, кроме, скажем, условия соединения, где соединение в int будет быстрее, чем соединение в varchar? или это так? (так как оба поля проиндексированы)

обновление: предполагается, что смена имени пользователя невозможна.

Answer 1

Я бы предпочел добавить дополнительное поле в качестве первичного ключа.

Основная причина в том, что -imho- первичные ключи не должны иметь значения 'business'.Первичный ключ - это просто административный элемент, который важен только для базы данных, так что целостность может быть гарантирована.
Как уже упоминал Брайан, добавив суррогатный первичный ключ, вы можете - в вашем случае - разрешить изменение пользователяего имя пользователя без проблем.

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

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

Answer 2

Прежде всего, я второй комментарий Фредерика: я твердо верю в то, чтобы не приписывать какую-либо деловую или функциональную ценность первичному ключу таблицы.Возможно, не будет возможности изменить имя пользователя сейчас, но, возможно, будет позже.Даже если нет, то лучше привыкнуть и соответствовать всем вашим таблицам, а не смешивать парадигмы.

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

Answer 3

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

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

Обратите внимание, что ваша база данных может генерировать правильный идентификатордля числового ПК через ряд средств.В MySQL это добавляет атрибут «auto_increment» в поле, в Postgres и Oracle - через последовательности.

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

Answer 4

Я бы добавил еще один столбец к существующему ключу. Добавление дополнительного поля к существующему первичному ключу также называется сцепленным первичным ключом.

http://www.relationaldbdesign.com/relational-database-analysis/module2/concatenated-primary-keys.php