sql - foreign - numérico(38,0) como columna de clave principal; bueno, malo, ¿a quién le importa?
insert sql (4)
Bueno, está gastando más datos para almacenar números que nunca alcanzará realmente.
bigint sube a 9,223,372,036,854,775,807 en 8 Bytes
int sube a 2,147,483,647 en 4 bytes
Un NUMERIC (38,0) va a tomar, si estoy haciendo el cálculo correcto, 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 (ya sea indexadas o buscadas en la página de datos). Pasa lo mismo para replicación, páginas de registro, etc.
Para SQL Server: INT es un estándar IEEE y, por lo tanto, es más fácil de comparar para la CPU, por lo que se obtiene un ligero aumento de rendimiento al usar INT frente a NUMERIC (que es un formato decimal empaquetado). (Nota en Oracle, si la versión actual coincide con las versiones anteriores en las que crecí, TODOS los tipos de datos están empaquetados, por lo que un INT interno es prácticamente lo mismo que un 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.
En mi proyecto actual, me encontré con nuestro script master DB. Observándolo más de cerca, noté que todas nuestras claves primarias originales tienen un tipo de datos numéricos (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 numérico (38,0) es una mejor alternativa.
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.
Salvo las consideraciones de almacenamiento y alguna 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 bases de datos de Oracle, ya que es un valor por defecto bastante grande que no necesita pensar cuando está creando una tabla, similar a usar INT o BIGINT de forma predeterminada en SQL Server.
Sería mejor usar 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.