SQL Server NUMERIC / DECIMAL точность против хранения

Question

Учитывая то, что MSDN указывает относительно хранилища SQL Server 2008 R2 с ЦИФРОВОЙ / ДЕЦИМАЛЬНОЙ точностью.

Точность от 1 до 9 составляет 5 байтов
Точность от 10 до 199 байтов

Так что, если в моем бизнес-обосновании логически требуется тип данных с 2 десятичными разрядами и точностью до 5 цифр, то фактической производительности или разницы в хранении не будет, если я определю его как NUMERIC (5, 2) или NUMERIC (9, 2) .

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

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

Answer 1

Числовое (5, 2) допускает числа до 999,99 включительно. Если вы попытаетесь вставить 1000.0 в это, вы получите арифметическое переполнение.

Числовой (9,2) позволяет числа до 9 999 999,99 * 1003 включительно *

Имейте в виду, что если вы планируете суммировать это значение, оставьте дополнительное место, в противном случае вы получите переполнение или вам придется выполнить явное приведение.

Они занимают одинаковое количество байтов. Поскольку они имеют одинаковый размер хранилища, они одинаковы на странице данных, в памяти, в индексах, при передаче по сети и т. Д.

Именно по этой причине я обычно выясняю, какое число размеров мне нужно хранить (если использовать числовое значение), затем увеличиваю точность (и, возможно, масштабируемость), так что я чуть ниже точки, где увеличивается размер хранилища. Так что, если мне нужно хранить до 99 миллионов с 4 десятичными знаками, это будет числовое значение (12,4). Для того же хранилища я могу иметь числовое значение (19,6) и дать некоторое безопасное место, когда бизнес-пользователь объявляет, что ему действительно нужно хранить там пару миллиардов.