Проверка работоспособности: плавает как первичные ключи?

Question

Я работаю со старой базой данных SQL Server 2000, смешивая часть ее информации с новым приложением, которое я создаю. Я заметил, что некоторые из первичных ключей в некоторых таблицах являются числами с плавающей точкой, а не целыми числами. Они не являются внешними ключами и все уникальны. Я не могу представить себе причину, по которой кто-то захочет, чтобы их уникальные идентификаторы первичного ключа были плавающими, но я ни в коем случае не эксперт по SQL. Итак, я предполагаю, что я спрашиваю, знает ли тот, кто спроектировал эту довольно обширную базу данных, что я не знаю?

Answer 1

В настоящее время я работаю с довольно большим пакетом бухгалтеров, где КАЖДЫЙ из 350+ таблиц имеет первичный ключ FLOAT (53).Все фактические значения являются целыми числами, и система строго проверяет, что они действительно есть (есть специальные функции, которые выполняют всю инкрементную работу).

Я задумался над этим дизайном, но я могу понять, почему он был выбран, и датьэто некоторые кредиты.С одной стороны, система достаточно велика, чтобы в некоторых таблицах находилось миллиард записей.С другой стороны, эти первичные ключи должны быть легко читаемыми из внешних приложений, таких как Excel или VB6, и в этом случае вы не хотите делать их БОЛЬШИМИ.

Следовательно, с плавающей точкой все в порядке.

Answer 2

Я работал с кем-то, кто использовал плавающие как PK в базах данных SQL Server. Он беспокоился о том, что не хватит чисел для идентификаторов, если он будет придерживаться INT. (32 бита на SQL Server.) Он просто посмотрел на диапазон с плавающей запятой и не задумывался над тем фактом, не говоря уже о том, что для больших чисел место не удерживается в числе из-за ограниченной точности. Поэтому его код для взятия MAX (PK) + 1.0 в какой-то момент вернет число, равное MAX (PK). Нехорошо. Я наконец убедил его не использовать float для суррогатных первичных ключей для будущих баз данных. Он вышел перед тем, как починить БД, над которой работал.

Чтобы ответить на ваш вопрос: «Итак, я думаю, что я спрашиваю: знает ли тот, кто спроектировал эту довольно обширную базу данных, что я не знаю?» Скорее всего НЕТ! По крайней мере, не в отношении выбора типов данных.

Answer 3

Число с плавающей точкой имеет одно интересное свойство: всегда можно вставить значение между двумя другими, за исключением патологического случая, когда у вас заканчиваются биты. Недостатком является то, что проблемы с представлением могут помешать вам ссылаться на строку по ключу; трудно сделать два значения с плавающей точкой равными друг другу.

Answer 4

Это ЧИСЛОВЫЙ (x, y) формат и ИДЕНТИЧНОСТЬ? Если это так, это может быть обновление более старой версии SQL Server. Back-in-the-day IDENTITY может быть только числовым форматом, а не обычным INT, который мы используем сегодня.

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

Так как похоже, что вы храните целые:

Чтобы ответить на исходный вопрос более прямо: если вы храните целые числа, используйте целочисленный тип данных. Хранить и сравнивать эффективнее.

Answer 5

К вашему сведению, есть другой взгляд на это:

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

Answer 6

Я работаю с базой данных Cerner Millenium в течение нескольких лет (под покровом которой она использует Oracle). Первоначально я был очень удивлен, увидев, что он использует числа с плавающей точкой для таблиц. Затем я столкнулся с идентификатором в нашей базе данных> 2 ^ 32, и запрос, который я написал, дал неправильные результаты, потому что я неправильно преобразовал его в INT, я понял, почему они это сделали. Я не считаю ни один из приведенных выше аргументов против использования чисел с плавающей точкой убедительным в реальном мире, где для ключей вам нужны только числа, «несколько большие», чем 2 ^ 32, а значение идентификатора всегда имеет вид #### ##. 0. (Никто не говорит об идентификаторе формы ######. ######.) Однако теперь, когда мы импортируем эти данные в хранилище SQL Server, и bigint доступен, мы собираемся пойти с bigint вместо float.