sql server - tipos - Razones para no usar un número de incremento automático para una clave principal
restricciones foreign key (16)
El método de procedimiento de incremento debe ser seguro para subprocesos. De lo contrario, es posible que no obtenga números únicos. Además, debe ser rápido, de lo contrario será un cuello de botella de la aplicación. Las funciones integradas ya han tenido en cuenta estos dos factores.
Actualmente estoy trabajando en la base de datos de otra persona donde las claves principales se generan a través de una tabla de búsqueda que contiene una lista de nombres de tabla y la última clave principal utilizada. Un procedimiento almacenado incrementa este valor y verifica que sea único antes de devolverlo al SP de "inserción" de llamada.
¿Cuáles son los beneficios de usar un método como este (o simplemente generar un GUID) en lugar de simplemente usar el número de identidad / automático?
No estoy hablando de claves primarias que realmente "signifiquen" algo como ISBN o códigos de producto, solo los identificadores únicos.
Gracias.
El uso de identificadores únicos le permitirá fusionar datos de dos bases de datos diferentes.
Tal vez tiene una aplicación que recopila datos en múltiples bases de datos y luego se "sincroniza" con una base de datos maestra varias veces durante el día. No tendría que preocuparse por las colisiones de teclas principales en este escenario.
O, posiblemente, desee saber cuál será la identificación de un registro antes de que realmente lo cree.
Es útil para los clientes poder preasignar un montón de ID para hacer una inserción masiva sin tener que actualizar sus objetos locales con las ID insertadas. Luego está todo el problema de replicación, como lo menciona Galwegian.
La única razón real para hacer esto es ser independiente de la base de datos (si las diferentes versiones de db utilizan diferentes técnicas de numeración automática).
El otro tema mencionado aquí es la capacidad de crear registros en múltiples lugares (como en la oficina central y en las laptops de los usuarios que viajan). Sin embargo, en ese caso, probablemente necesitaría algo así como un "código de sitio" que fuera exclusivo de cada instalación que tenía el prefijo para cada ID.
Otra posible razón es que deliberadamente quieres llaves al azar. Esto puede ser deseable si, por ejemplo, no desea navegadores curiosos que hojeen cada elemento que tiene en la base de datos, pero no es lo suficientemente crítico como para garantizar medidas de seguridad de autenticación reales.
Preferiría usar un GUID para la mayoría de los escenarios en los que el método actual de la publicación tiene sentido para mí (la replicación es posible). Si la replicación era el problema, dicho procedimiento almacenado debería conocer el otro servidor, que debería estar vinculado para garantizar la singularidad de la clave, lo que lo haría muy frágil y probablemente una forma pobre de hacerlo.
Una situación en la que uso claves primarias enteras que NO son identidades autoincrementadas es el caso de tablas de búsqueda raramente cambiadas que imponen restricciones de clave externa, que tendrán una enumeración correspondiente en la aplicación que consume los datos. En ese escenario, quiero asegurarme de que la asignación enum será correcta entre el desarrollo y la implementación, especialmente si habrá múltiples servidores de prueba.
Un ID generado automáticamente puede causar problemas en situaciones en las que está utilizando la replicación (¡ya que estoy seguro de que las técnicas que ha encontrado pueden hacerlo!). En estos casos, generalmente opto por un GUID.
Si no es probable que use la replicación, entonces un PK de incremento automático funcionará muy bien.
Un beneficio es que puede permitir que la base de datos / SQL sea más multiplataforma. El SQL puede ser exactamente el mismo en SQL Server, Oracle, etc.
Una ventaja adicional útil de usar una clave principal GUID en lugar de una de autoincrementación es que puede asignar el valor PK para una nueva fila en el lado del cliente (de hecho, debe hacerlo en un escenario de replicación), evitándole el molestia de recuperar el PK de la fila que acaba de agregar en el servidor.
Una de las desventajas de un GUID PK es que las uniones en un campo GUID son más lentas (a menos que esto haya cambiado recientemente). Otra ventaja del uso de GUID es que es divertido intentar explicar a un administrador no técnico por qué es poco probable una colisión GUID.
de CodingHorror :
GUID Pros
- Único en cada mesa, cada base de datos, cada servidor
- Permite una fácil fusión de registros de diferentes bases de datos
- Permite una fácil distribución de bases de datos en múltiples servidores
- Puede generar identificadores en cualquier lugar, en lugar de tener que hacer un viaje de ida y vuelta a la base de datos
- La mayoría de los escenarios de replicación requieren columnas GUID de todos modos
GUID Contras
- Es una friolera 4 veces más grande que el valor del índice tradicional de 4 bytes; esto puede tener serias implicaciones de rendimiento y almacenamiento si no tiene cuidado
- Es complicado depurar (donde userid = ''{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'')
- Los GUID generados deben ser parcialmente secuenciales para un mejor rendimiento (p. Ej., Newsequentialid () en SQL 2005) y para permitir el uso de índices agrupados
El artículo proporciona una gran cantidad de buenos enlaces externos para tomar la decisión sobre el GUID frente al aumento automático. Si puedo, voy con GUID.
La única razón por la que puedo pensar es que el código fue escrito antes de que las sequences fueran inventadas y el código se olvidara de ponerse al día;)
No hay nada inherentemente incorrecto con el uso de Autonumérico, pero hay algunas razones para no hacerlo. Aún así, lanzar tu propia solución no es la mejor idea, como mencionó Dacracot. Dejame explicar.
La primera razón para no usar Autonumérico en cada tabla es que puede terminar fusionando registros de varias tablas. Supongamos que tiene una tabla de pedidos de venta y otro tipo de tabla de pedidos, y decide extraer algunos datos comunes y utilizar la herencia de tablas múltiples. Es bueno tener claves primarias que son globalmente únicas. Esto es similar a lo que dijo bobwienholt sobre la fusión de bases de datos, pero puede ocurrir dentro de una base de datos.
Segundo, otras bases de datos no usan este paradigma, y otros paradigmas como las secuencias de Oracle son mucho mejores. Afortunadamente, es posible imitar secuencias de Oracle utilizando SQL Server. Una forma de hacerlo es crear una sola tabla Autonumérico para toda su base de datos, llamada MainSequence, o lo que sea. Ninguna otra tabla en la base de datos usará el autonumber, pero cualquiera que necesite una clave primaria generada automáticamente usará MainSequence para obtenerla. De esta forma, obtienes todo el rendimiento, bloqueo, seguridad de hilos, etc. de los que dacracot hablaba sin tener que construirlo tú mismo.
Otra opción es usar GUID para claves primarias, pero no lo recomiendo, porque incluso si está seguro de que un ser humano (incluso un desarrollador) nunca va a leerlos, probablemente alguien lo haga, y es difícil. Y, lo que es más importante, las cosas se convierten implícitamente en ints muy fácilmente en T-SQL pero pueden tener un montón de problemas al convertir implícitamente a un GUID. Básicamente, son inconvenientes.
Al construir un nuevo sistema, recomendaría usar una tabla dedicada para la generación de claves primarias (como las secuencias de Oracle). Para una base de datos existente, no me desviaría de mi camino para cambiarlo.
Mi principal problema con las teclas de incremento automático es que carecen de significado
Ese es un requisito de una clave primaria, en mi opinión, no tener otra razón para existir que no sea la identificación de un registro. Si no tiene un significado en el mundo real, entonces no tiene un motivo real para cambiar. No quiere que las claves principales cambien, en general, porque tiene que buscar-reemplazar su base de datos completa o algo peor. Me he sorprendido del tipo de cosas que he asumido serían únicas e inmutables que no han resultado ser años después.
Aquí está la cosa con números enteros incrementales automáticos como claves:
TIENE que haber publicado el registro antes de tener acceso a él. Eso significa que hasta que haya publicado el registro, no puede, por ejemplo, preparar registros relacionados que se almacenarán en otra tabla, o cualquiera de muchas otras razones posibles por las que podría ser útil tener acceso a los registros únicos del nuevo registro id, antes de publicarlo.
Lo anterior es mi factor decisivo, ya sea que vaya con un método, o el otro.
La respuesta de Galwegian no es necesariamente cierta.
Con MySQL puede establecer un desplazamiento de clave para cada instancia de base de datos. Si combina esto con un incremento lo suficientemente grande, lo hará por multa. Estoy seguro de que otros proveedores tendrían algún tipo de configuración similar.
Digamos que tenemos 2 bases de datos que queremos replicar. Podemos configurarlo de la siguiente manera.
increment = 2
db1 - offset = 1
db2 - offset = 2
Esto significa que
db1 tendrá las teclas 1, 3, 5, 7 ...
db2 tendrá claves 2, 4, 6, 8 ....
Por lo tanto, no tendremos choques clave en las inserciones.
Mi problema principal con las teclas de incremento automático es que carecen de significado.
Para las tablas donde ciertos campos proporcionan exclusividad (ya sea solo o en combinación con otro), optaría por usar eso en su lugar.