Teclas primarias negativas

¿Hay alguna repercusión al usar claves primarias negativas para tablas (Aumento de identidad -1, Identity Seed -1 en SQL Server 2005)?Teclas primarias negativas

El motivo es que estamos creando una nueva base de datos para reemplazar una existente. Existen tablas similares entre las dos bases de datos y nos gustaría que la "fuente" de la información sea transparente para nuestras aplicaciones. El enfoque es crear vistas que unan las tablas de ambas bases de datos. Las PK negativas garantizan que las identidades no se superpongan.

Fuente

2010-03-18 bjaxbjax

Considere la posibilidad de importar los datos de la base de datos anterior a la nueva (creando nuevos valores de PK), en lugar de mantener las tablas antiguas y crear vistas. El rendimiento será mejor y tendrás menos complejidad para enfrentar en el futuro. –

Eso sería ideal, pero las luces deben dejarse en las aplicaciones heredadas y DB hasta que se complete la nueva plataforma. Mientras tanto, las nuevas aplicaciones necesitan acceder a la información de ambas ubicaciones. – bjaxbjax

Creo que tener 2 fuentes no es la razón correcta para este enfoque, aunque técnicamente permitido. No es escalable. – Tengiz

Como han dicho otros, la base de datos está bien con esto.

Pero sería un problema para una aplicación .NET que utiliza DataSet + DataAdapter ya que utilizan claves negativas como temporales para nuevos registros.

Otras capas de acceso a datos pueden usar trucos similares.

Fuente

2010-03-18 20:53:13

Gracias por el cara a cara Henk. Estamos usando una capa de acceso a datos personalizada por el momento, pero estaremos atentos a situaciones como esta en el futuro. – bjaxbjax

Tenga en cuenta que un INSERT ya no es una simple operación de adición si tiene su clave principal como un índice agrupado. – erikkallen

No hay problema.

Es poco ortodoxo, pero aparte de eso, está bien.

El valor predeterminado que ofrece SQL Server es simplemente eso, un valor predeterminado, y puede modificarse según las necesidades. Parece que tienes un buen compromiso.

Fuente

2010-03-18 20:43:46 Oded

Esto está perfectamente bien desde la perspectiva de SQL Server. La verdadera pregunta va a ser tu aplicación.

Fuente

2010-03-18 20:44:12 NotMe

¡El único problema es que no podrá agregar una tercera fuente de datos de esta manera!

Fuente

2010-03-18 20:45:11

+17

A menos que comiencen a usar números imaginarios ... Entonces podrían tener claves como 1 + 2 * i * – FrustratedWithFormsDesigner

No es un problema. Solo asegúrese de que su columna Identity sea de un tipo que permita números negativos.

Fuente

2010-03-18 20:46:21

Deseará revisar el código heredado y buscar dónde los desarrolladores han ordenado la clave principal como una forma lenta o descuidada de ordenar por fecha (porque los pk de identidad generalmente están correlacionados fuerte o perfectamente con el tiempo).

Fuente

2010-03-18 20:46:23 MatthewMartin

Si los números negativos resultan para romper algo, use los números pares para uno y los números impares para el otro.

Fuente

2010-03-18 20:50:15

Otra opción es añadir un prefijo a las claves heredadas con una cadena como "OLD_". El problema es que su campo clave no será numérico.

Si tiene que tener claves numéricas, puede introducir una columna de indicador "heredado", y la clave principal sería una combinación de la ID numérica y el indicador heredado (con suerte, esa combinación debe ser única).

Fuente

2010-03-18 21:00:58 FrustratedWithFormsDesigner

Creo que tener 2 fuentes no es la razón correcta para este enfoque, aunque técnicamente permitido. No es escalable (+1 a la respuesta de Larry Lustig por eso).

Solo crearía una vista o procedimiento almacenado que combine ambos datos, convirtiendo los ID según sea necesario, y tendría una aplicación para usarlo en lugar de lecturas directas de tablas y uniones. Esto sería escalable al modificar la vista/SP más tarde para agregar una fuente más.

Fuente

2015-12-28 20:09:43 Tengiz

Respuesta

Cuestiones relacionadas