Есть ли какая-либо причина для numeric, а не int в T-SQL?



Зачем кому-то использовать числовой(12, 0) Тип данных для простого целочисленного столбца ID? Если у вас есть причина, почему это лучше, чем int или bigint, я хотел бы ее услышать.



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



Я составляю список ошибок программирования и проблем с производительностью продукта, и я хочу быть уверен, что они не сделали этого по какой-то логической причине. Если вы будете следовать этому ссылка:
http://msdn.microsoft.com/en-us/library/ms187746.aspx



... вы можете видеть, что число (12, 0) использует 9 байт памяти и, будучи ограничено 12 цифрами, в общей сложности 2 триллиона чисел, если вы включаете отрицательные значения. Зачем человеку использовать это, когда он может использовать bigint и получить в 10 миллионов раз больше чисел с одним байтом меньше памяти. Кроме того, поскольку это используется в качестве идентификатора продукта, 4 миллиарда номеров стандартного int были бы больше, чем достаточно.



Итак, прежде чем я возьму факелы и вилы, скажите мне, что они собираются сказать в свою защиту?

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

815   9  

9 ответов:

Возможно, они привыкли работать с Oracle?

Все числовые типы, включая ints, нормализованы к стандартному единственному представлению среди всех платформ.

Есть много причин использовать числовые-например, финансовые данные и другие материалы, которые должны быть точными до определенных десятичных знаков. Однако для примера, который вы привели выше, достаточно простого int.

Возможно, работают неаккуратные программисты, которые не знают, как создать базу данных ?

Сколько лет этому приложению, которое вы рассматриваете?

До SQL Server 2000 не было никакого bigint. Может быть, это просто что-то, что делало его от выпуска к выпуску в течение многих лет, не меняясь, или схема базы данных была скопирована из приложения, которое было таким старым?!?

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

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

Ваше наблюдение верно, но вы, вероятно, не хотите представлять его слишком сильно, если вы уменьшаете объем памяти с 5000 байт до 4090 байт, например.

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

Можете ли вы заполнить эти пробелы?

with the data type change, we use
    ____ bytes of disk space instead of ____
    ____ ms per query instead of ____
    ____ network bandwidth instead of ____
    ____ network latency instead of ____

Это то, что даст вам доверие.

В некоторых базах данных использование десятичной дроби (10,0) создает упакованное поле, которое занимает меньше места. Я знаю, что есть много столов вокруг моей работы, которые используют это. У них, вероятно, была такая же мысль здесь, но вы обратились к документации и доказали, что это неверно. Скорее всего, я бы сказал, что это будет сводиться к случаю "так мы всегда делали, потому что кто-то однажды сказал, что это лучше".

Вполне возможно, что они проводят много времени в MS Access и часто видят "число" и просто считают, что это число, почему бы не использовать числовое?

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

Интересно, насколько эффективен индекс десятичного значения (даже если задана шкала 0) для первичного ключа по сравнению с чистым целочисленным значением.

Как Марк Х. сказал, что, кроме фактора индексирования, этот конкретный сценарий, скорее всего, не увеличивает базу данных так сильно, но если вы ищете боеприпасы, я думаю, что вы нашли некоторые, чтобы принизить их.

В вашей цитате десятичное число показывает точность 1-9 при использовании 5 байт. Ваш столбец, по-видимому, имеет 12,0-используя 4 байта памяти-то же самое, что целое число.

Кроме того, INT, datatype может перейти в степень 31: От -2^31 (-2,147,483,648) до 2^31-1 (2,147,483,647)

В то время как десятичное число намного больше 38: - 10^38 +1 через 10^38-1

Таким образом, создатель программного обеспечения фактически предоставлял больше, используя тот же объем пространства для хранения.

Теперь, с основами из таким образом, создатель программного обеспечения фактически ограничил себя только 12 числами или 123 456 789 012 (просто пример для владельцев мест, а не максимальное число). Если бы они использовали INT, они не могли бы масштабировать этот столбец - он поднялся бы до полных 31 цифр. Возможно, есть бизнес-причина ограничить этот столбец и связанные с ним столбцы до 12 цифр.

INT - это INT, а десятичное число-скалярное.

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

PS: Аргументом целого числа является: А) целые числа-это 0..бесконечность Б) счетные (натуральные) числа равны 1..бесконечность В) целые числа бесконечны (отрицательны).. бесконечность (положительная) Г) Я бы ни за что не стал цитировать WikiANYTHING. Давай, используй настоящий источник! Может также быть http://MyPersonalMathCite.com

Согласно: http://doc.ddart.net/mssql/sql70/da-db_1.htm

Десятичная

Фиксированная точность и масштаб числовых данных от -10^38 -1 до 10^38 -1.

Числовой

Синоним десятичной дроби.

Int

Целочисленные (целое число) данные от -2^31 (-2,147,483,648) до 2^31 - 1 (2,147,483,647).

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

Comments

    Ничего не найдено.