Должен ли я использовать целые первичные идентификаторы?

Question

Например, я всегда создаю поле auto-increment для таблицы users, но я также указываю индекс UNIQUE для своих имен пользователей. Есть ситуации, когда мне сначала нужно получить userId для данного имени пользователя, а затем выполнить требуемый запрос или использовать JOIN в желаемом запросе. Это 2 поездки в базу данных или JOIN против индекса varchar.

Должен ли я использовать целые первичные идентификаторы?

Есть ли реальное преимущество в производительности на INT более small Показатели VARCHAR?

Answer 1

Есть несколько преимуществ, имеющие суррогатный первичный ключ, в том числе:

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

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

Answer 2

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

Кстати, я часто масштабирую тип int до размера таблицы. Когда я знаю, что таблица не будет превышать 255 строк, я использую ключ tinyint и тот же для smallint.

Answer 3

В дополнение к тому, что говорили другие, вам нужно подумать о кластеризации таблицы.

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

Сравните это с первичным ключом направляющей - новые строки должны быть вставлены в середину таблицы, потому что направляющие не являются последовательными, что делает вставки очень неэффективными.

Answer 4

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

1. Использование 32-бит будет потреблять только 4 байта памяти. Предположительно, ваши имена пользователей будут длиннее четырех символов, отличных от Юникода, и, следовательно, потребляют более 4 байтов пространства. Чем больше места используется, тем немногие данные будут помещены на странице, чем толще индекс, тем больше вы берете на себя.

2. В столбцах персонажей потребуется использование varchar над char, если вы не заставите всех иметь имена пользователей одинакового размера. Это также будет иметь незначительное влияние на производительность и хранение.

3. Если вы не используете сортировку двоичных сортировок, система должна выполнять сопоставимые сопоставления при сравнении двух строк. Используются ли эти два столбца для одного столбца? Для каждого персонажа они одинаковы? Каковы правила обсадной колонны и акцента в отношении соответствия? и так далее. Хотя это можно сделать быстро, это большая работа, которая в очень больших таблицах может иметь значение по сравнению с сопоставлением целого числа.

Я не уверен, зачем вам приходилось делать две поездки в базу данных или присоединиться к столбцу varchar. Почему вы не могли сделать одну поездку в базу данных (где создание возвращает ваш новый ПК), где вы присоединяетесь к таблице пользователей на целочисленной PK?