Индекс SQL - разница между char и int - PullRequest
0 голосов
/ 28 февраля 2011

У меня есть таблица в базе данных Sql Server 2005. Поле первичного ключа таблицы - это кодовый номер.

Как правило, код должен содержать ровно 4 цифры. Например: 1234, 7834, ...

Вы предлагаете, чтобы тип поля был char (4) или int или numeric (4) с точки зрения эффективной операции выбора. Будет ли индексирование таблицы по любому из них отличаться от любого другого?

Ответы [ 4 ]

1 голос
/ 28 февраля 2011

Столбцы Integer / Identity часто используются для первичных ключей в таблицах базы данных по ряду причин.Столбцы первичного ключа должны быть уникальными, не должны обновляться и действительно не иметь смысла.Это делает столбец идентификаторов довольно хорошим выбором, потому что сервер получит следующее значение за вас, они должны быть уникальными, а целые числа относительно малы и полезны (по сравнению с GUID).

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

  1. Наилучшим выбором для первичного ключа являются целочисленные типы данных, поскольку целочисленные значения обрабатываются быстрее, чемсимвольные значения типа данных.Символьный тип данных (в качестве первичного ключа) необходимо преобразовать в эквивалентные значения ASCII перед обработкой.
  2. Выборка записи на основе первичного ключа будет быстрее в случае целых чисел в качестве первичных ключей, поскольку это будет означатьбольше записей индекса будет присутствовать на одной странице.Таким образом, общее время поиска уменьшается.Также соединения будут быстрее.Но это будет применимо, если ваш запрос использует поиск по кластерному индексу, а не сканирование, и если используется только одна таблица.В случае сканирования без дополнительного столбца будет означать больше строк на одной странице данных.

Надеюсь, это поможет вам!

1 голос
/ 28 февраля 2011

Я защищаю НЕБОЛЬШУЮ колонку. Просто потому, что это наиболее разумный тип данных, который будет соответствовать требуемому диапазону (до 65535, более 4 цифр). Используйте проверочное ограничение для принудительного применения 4-значного ограничения и столбец COMPUTED для возврата столбца char (4).

0 голосов
/ 28 февраля 2011

«Это зависит»

  • В в этом случае char (4) захватывает данные, сохраненные правильно, без дополнительной памяти (по 4 байта каждая).И 0001, конечно, не то же самое, что 1.

  • У вас есть некоторые накладные расходы на обработку параметров сортировки и т. Д., Если у вас есть нецифровые цифры, но это не должно иметь значениядля баз данных разумного размера.И с 4-значным кодом у вас есть верхняя граница для числа строк, особенно если числовой (10k).

  • Если ваши новые коды не увеличиваются строго, то вы получите разделение страницыпроблема, связанная с кластеризованными ключами GUID

  • Если они строго увеличиваются, используйте int и добавьте вычисляемый столбец для добавления ведущих нулей

0 голосов
/ 28 февраля 2011

Если я правильно помню, целые числа занимают меньше места, чем символы, поэтому вам следует использовать int. Эти две ссылки говорят одно и то же:
http://www.eggheadcafe.com/software/aspnet/31759030/varcharschars-vs-intbigint-as-keys.aspx
http://sql -server-performance.com / Сообщество / форумы / р / 16020 / 94489.aspx

...