SQL Server NUMERIC/DECIMAL precisión frente a almacenamiento

Question

Considerando lo que dice MSDN con respecto al almacenamiento de SQL Server 2008 R2 de precisión NUMÉRICA/DECIMAL.

precisión del 1 al 9 es de 5 bytes
precisión de 10 a 19 es de 9 bytes

Así que si mi modelo de negocio requiere lógicamente un tipo de datos con 2 decimales y una precisión de 5 dígitos no hace ninguna diferencia real de rendimiento o almacenamiento si lo defino como NUMERIC (5, 2) o NUMERIC (9, 2).

Una de las razones por las que ignoro intencionalmente es la restricción de verificación implícita ya que probablemente pondría una restricción de verificación real en la columna que limita el rango real permitido.

¿Esto hace una diferencia cuando se trata de índices, rendimiento de consultas o cualquier otro aspecto del sistema?

Answer 1

Numérico (5, 2) permite números hasta e incluyendo 999.99. Si intenta insertar 1000.0 en eso, obtendrá un desbordamiento aritmético.

numérico (9,2) permite que los números hasta e incluyendo 9 999 999,99

Tenga en cuenta que si va a resumir nunca este valor, deje espacio adicional, de lo contrario obtendrá un desbordamiento o' Necesitaré hacer un lanzamiento explícito.

Toman la misma cantidad de bytes. Como tienen el mismo tamaño de almacenamiento, son los mismos en la página de datos, en la memoria, en los índices, en la transmisión de red, etc.

Es por esta razón que normalmente resuelvo qué número de tamaño necesito para almacenar (si usa numérico), luego aumente la precisión (y tal vez la escala) para que esté justo por debajo del punto donde aumenta el tamaño de almacenamiento. Entonces, si necesito almacenar hasta 99 millones con 4 posiciones decimales, eso sería numérico (12,4). Para el mismo almacenamiento, puedo tener un valor numérico (19,6) y dar un espacio seguro para cuando el usuario comercial anuncie que realmente necesita almacenar un par de miles de millones allí.