Числовой (38,0) в качестве столбца первичного ключа; хорошо, плохо, кого это волнует?

В моем текущем проекте я наткнулся на наш мастер DB script. Познакомившись с этим, я заметил, что все исходные первичные ключи имеют тип данных числовой (38,0) В настоящее время мы запускаем SQL Server 2005 в качестве нашей основной платформы БД.

В небольшом контексте мы поддерживаем Oracle и SQL Server как наш сервер. В Oracle наши первичные ключи имеют тип данных (38,0).

Кто-нибудь знает о возможных побочных эффектах и воздействии такой реализации? Я всегда выступал и реализовал int или bigint в качестве первичных ключей и хотел бы знать, является ли числовая (38,0) лучшей альтернативой.

Ответ 1

Хорошо, вы тратите больше данных на хранение номеров, которые вы никогда не достигнете.

bigint идет до 9,223,372,036,854,775,807 в 8 байтах

int переходит в 2 147 483 647 в 4 байта

Будет выполняться NUMERIC (38,0), если я делаю математическое право, 17 байт.

Не большая разница, но: меньшие типы данных = больше строк в памяти (или меньше страниц для одной и той же строки) = меньше ввода/вывода на диске для поиска (как индексированные, так и поисковые страницы). Идет то же самое для репликации, журнальных страниц и т.д.

Для SQL Server: INT является стандартом IEEE, поэтому сравнить процессор с ним проще, поэтому вы получаете небольшое увеличение производительности с помощью INT или NUMERIC (который представляет собой упакованный десятичный формат). (Примечание в Oracle, если текущая версия соответствует более старым версиям, на которых я вырос, все типы данных упакованы, поэтому INT внутри - это почти то же самое, что и NUMERIC (x, 0), поэтому нет разницы в производительности)

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

В противном случае в этот момент я оставил бы это как есть. Не нужно ничего менять.

Ответ 2

Устранение соображений хранения и некоторая первоначальная путаница со стороны будущих администраторов баз данных, я не вижу причин, по которым NUMERIC (38,0) будет плохой идеей. Вы разрешаете до 9.99 x 10 ^ 38 записей в таблице, чего вы, конечно, никогда не достигнете. Моя быстрая копания в этом не вызвала ни одной вопиющей причины, чтобы не использовать ее. Я подозреваю, что вашей единственной потенциальной проблемой будет пространство для хранения, затраченное на это, но, видя, как пространство для хранения настолько дешево, это не должно быть проблемой.

Я видел это довольно много раз в базах данных Oracle, так как это довольно большое значение по умолчанию, о котором вам не нужно думать, когда вы создаете таблицу, аналогично использованию INT или BIGINT по умолчанию в SQL Сервер.

Ответ 3

Вам будет лучше использовать GUID. В самом деле. Обычная причина не использовать его в том, что целое число работает лучше. Но GUID меньше числового (38) и имеет дополнительное преимущество, заключающееся в том, что сделать его немного легче сделать, например, чтобы отключенные пользователи создавали и синхронизировали новые записи.

Ответ 4

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

Я не думаю, что он достаточно разбит, чтобы беспокоиться о фиксации.