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

Question

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

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

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

Answer 1

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

bigint увеличивается до 9 223 372 036 854 775 807 в 8 байтах

int увеличивается до 2 147 483 647 в 4 байтах

ЧИСЛО (38,0) получит, если я правильно делаю математику, 17 байт.

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

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

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

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

Answer 2

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

Answer 3

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

Не думаю, что он достаточно сломан, чтобы беспокоиться об исправлении.

Answer 4

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

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