numérico (38,0) como columna de clave principal; bueno, malo, ¿a quién le importa?

Question

En mi proyecto actual, me encontré con nuestro script maestro DB. Al examinarlo más de cerca, noté que todas nuestras claves primarias originales tienen un tipo de datos de numeric (38,0) Actualmente, estamos ejecutando SQL Server 2005 como nuestra plataforma de base de datos primaria.

Para un pequeño contexto, admitimos Oracle y SQL Server como nuestro back-end. En Oracle, nuestras claves principales tienen un tipo de datos de número (38,0).

¿Alguien sabe de los posibles efectos secundarios y el impacto en el rendimiento de dicha implementación? Siempre he defendido e implementado int o bigint como claves principales y me encantaría saber si la opción numérica (38,0) es una mejor alternativa.

Answer 1

Bueno, usted es gastando más datos para almacenar números que nunca alcanzará realmente.

bigint sube 9.223.372.036.854.775.807 en 8 Bytes

int sube 2147483647 de 4 bytes

un valor numérico (38,0) va a tomar, si estoy haciendo la derecha matemáticas, 17 bytes .

No es una gran diferencia, pero: tipos de datos más pequeños = más filas en la memoria (o menos páginas para el mismo número de filas) = ​​menos E/S de disco para realizar búsquedas (búsqueda de páginas indexadas o de datos). Pasa lo mismo para replicación, páginas de registro, etc.

Para SQL Server: INT es un estándar IEEE y es más fácil para la CPU comparar, por lo que obtiene un ligero aumento de rendimiento al usar INT vs. NUMERIC (que es un formato decimal empaquetado). (Nota en Oracle, si la versión actual coincide con las versiones anteriores, TODOS los tipos de datos están empaquetados, por lo que INT interior es más o menos lo mismo que NUMERIC (x, 0) por lo que no hay diferencia de rendimiento)

Entonces, en el gran esquema de cosas, si tiene muchos discos, RAM y E/S de repuesto, use el tipo de datos que desee. Si quieres obtener un poco más de rendimiento, sé un poco más conservador.

De lo contrario, en este punto, lo dejaría como está. No hay necesidad de cambiar las cosas.

Answer 2

Al no tener en cuenta las consideraciones de almacenamiento y la confusión inicial de futuros DBA, no veo ninguna razón por la cual NUMERIC (38,0) sería una mala idea. Está permitiendo registros de hasta 9.99 x 10^38 en su tabla, que nunca alcanzará. Mi búsqueda rápida de esto no arrojó ninguna razón obvia para no usarlo. Sospecho que su único problema potencial será el espacio de almacenamiento consumido por eso, pero teniendo en cuenta que el espacio de almacenamiento es tan económico, eso no debería ser un problema.

Lo he visto muchas veces en las bases de datos de Oracle, ya que es un valor por defecto bastante grande que no necesita pensar cuando está creando una tabla, similar al uso de INT o BIGINT por defecto en Servidor SQL.

Answer 3

Esto es demasiado grande porque nunca tendrá tantas filas. El tamaño más grande dará como resultado más espacio de almacenamiento. Esto no es un gran problema en sí mismo, pero también significará más lecturas de disco para recuperar datos de una tabla o índice. Significará que menos filas caben en la memoria en el servidor de la base de datos.

No creo que esté roto lo suficiente como para molestarse en arreglarlo.

Answer 4

Sería mejor utilizar un GUID. De Verdad. La razón normal para no usar uno es que un entero funciona mejor. Pero el GUID es más pequeño que el numérico (38), y tiene el beneficio adicional de hacer que sea un poco más fácil hacer cosas como permitir que los usuarios desconectados creen y sincronicen nuevos registros.