tool - sql diagram online
¿Por qué los diseñadores de bases de datos no hacen que las columnas de IDENTIDAD comiencen desde el valor mínimo en lugar de 1? (6)
Al pasar de los números negativos a los positivos, cruzarás a cero. Eso significa (suponiendo que en realidad está insertando un par de miles de millones de filas) que eventualmente tendrá un identificador de cero. Esto no es intrínsecamente malo, pero podría presentar un posible caso marginal para las herramientas ORM o simplemente un código de aplicación descuidado que tiene dificultad para diferenciar entre cero y nulo.
Como sabemos, en SQL Server, la IDENTITY (n,m) significa que los valores comenzarán desde n , y el valor de incremento es m , pero noté que todos los diseñadores de bases de datos crean columnas de Identidad como IDENTITY(1,1) , sin aprovechando todos los valores del tipo de datos int que son de (-2,147,483,648) to (2,147,483,647) ,
Estoy planeando convertir todas las columnas de identidad en IDENTITY (-2,147,483,648, 1) , (las columnas de identidad están ocultas para el usuario de la aplicación).
Es eso una buena idea ?
En el lado del Servidor SQL, los identificadores negativos son correctos, manejados como números positivos, por lo que podría hacer eso.
Los otros tienen razón, debe pensar en sugerencias diferentes, pero los principales problemas son las aplicaciones conectadas a su base de datos.
Vamos a decir tomar MS Enviroment. Aquí hay un ejemplo: .NET DataSet está utilizando identificadores negativos -s en identificadores autoincrementados para rastrear los cambios en un código. Entonces puede tener problemas, porque:
Las claves negativas se utilizan para instancias temporales para las filas.
Aquí está la referencia: MSDN
Definitivamente no es una buena idea diseñar una base de datos como esta para MSSQL en un entorno de MS.
Las identificaciones negativas pueden ser útiles para probar en un entorno real donde los datos ficticios deben mezclarse con datos reales para fines de prueba, y luego eliminarse una vez que se completen las pruebas. Esto debe hacerse solo por una muy buena razón: solo he usado la técnica una vez.
Las identificaciones negativas también pueden ser útiles para fines de administrador en tablas de solo lectura y solo lectura (es decir, sin transacciones, no se ejecuta SQL ejecutable en la tabla).
Además de esos propósitos específicos, los valores de identidad <= 0 generarán más calor que luz.
Si encuentra que los 2 billones de valores no son suficientes, descubrirá que 4 billones tampoco es suficiente (que necesita más del doble de lo que dure la vida del proyecto, para lo que fue diseñado por primera vez, es difícil raro *), por lo que debe tomar un enfoque diferente por completo (posiblemente valores largos, posiblemente algo totalmente diferente).
De lo contrario, solo estás siendo extraño e ilegible sin ningún beneficio.
Además, ¿quién no tiene una base de datos donde saben que, por ejemplo, el elemento 312 es el que tiene algunas características agradables para probar cosas particulares? Sé que tengo algunos IDs arbitrarios quemados en mi cabeza. Pueden llamarlo "tan bueno que lo nombraron dos veces", pero siempre conoceré Nueva York como "la ciudad 657, cubre la mayoría de nuestros casos de prueba". Es solo una abreviatura, pero -2147482991 no sería tan útil.
* Para agregar un poco a eso. Con algunas cosas, puede decir "ah aproximadamente 100" y descubrir que en realidad son 110, está bien. Con otros descubrirás que en realidad son 100.000: has salido por órdenes de magnitud. Cuanto mayor es el número, más a menudo el error es de este tipo debido a la clase de problemas que terminan con estimaciones en miles de millones que son diferentes a las que terminan con respuestas en docenas. Si estima que 200 es su máximo en un caso determinado, probablemente debería dejar espacio para unos cientos más. Si estima 2 billones en un caso dado, probablemente debería dejar espacio para unos cuantos trillones más. Dicho esto, la única vez que vi a alguien iniciar una identificación en menos de 2 billones terminaron teniendo unas 3.000 filas.
Si tiene una clase que representa su tabla en su código (que es muy probable que suceda), cada vez que cree un nuevo objeto, se le asignará la ID 0 de forma predeterminada. Podría conducir a errores que sobrescriben datos en la base de datos si el ID 0 ya está asignado. Esto también facilita la determinación de si un objeto es nuevo o si proviene de la base de datos simplemente haciendo if (myObject.ID != 0)
Uno de los ''buenos'' efectos secundarios de trabajar con números enteros cercanos a cero es que son fáciles de usar y fáciles de recordar para los desarrolladores, probadores, etc., especialmente teniendo en cuenta la depuración y las pruebas unitarias.
Además, las claves sustitutas tienen la desagradable costumbre de introducirse en la terminología comercial, por ejemplo, los usuarios pueden ver el PK en la cadena de consulta URL en la parte superior del navegador: cuantos más dígitos haya en el número, más probabilidades tendrán de citar incorrectamente algo en una consulta de Helpdesk.
Así que esta es una de las razones por las que estoy feliz de sembrar mis identidades en 1, y no en -2147483231, y en su lugar, como lo sugiere @Jon, pasar a BIGINT cualquier momento que pueda necesitar algo más que 2 mil millones de filas en mi mesa