Columnas de identidad o UDF que genera explícitamente un identificador único?

Question

Estoy en medio de un debate sobre si es mejor hacer una PRIMARY KEY cabo de un columnas de identidad , nuestra salida de una UDF que genera explícitamente un único ID.

• que argumento para la columna de identidad.
• Mi pareja está discutiendo para generar los valores manualmente, afirma
  • poniendo la UDF en otra mesa donde podemos tener una UDF
    • bloquear el recurso
    • incrementar una tabla de ID con un solo campo llamado ID_Value por 1
    • utilizar esto como un identificador único global
  • O es que la tabla haga una id+1 al insertar
  • Esto es más fácil de mover datos entre servidores y / o entornos no tienen la restricción de identificar; pasar de una base de datos donde hay datos a otra base de datos similar con puesta en escena le digamos o datos ficticios. Para la prueba en la producción no podemos querer tirar de todos los registros de ayer hasta puesta en escena para la prueba.

¿Qué aplicación tiene más sentido?

Answer 1

Su colega es un idiota.

La solución no será escalable, el UDF no es concurrente ( misma razón que este ). Y, ¿cómo lidiar con inserciones de varias filas: esto requeriría una llamada UDF por fila

Y la migración a otros RDBMS no sucede a menudo en la vida real ... es posible que así no utilizar SQL Server ahora y secuencias de uso de Oracle y espero que no migran.

Editar:

Sus actualización de estados que el movimiento de datos es para actualizar las bases de datos no son de producción.

En ese caso, se ignoran las columnas de identidad en el refresco. No comprometer su aplicación para que no prod facilitar la carga. O tablas de uso temporales para realizar un seguimiento de los cambios de valor de identidad.

o procesos de uso: refrescamos nuestro sistema de prueba todas las noches de la producción que evita el problema por completo. (Y asegura nuestra copia de seguridad prod puede ser restaurado también)

Answer 2

Utilice un valor de identidad. Generar sus propios valores de la tabla de secuencia y secuencia tendrá una gran cantidad de gastos generales y causar una gran cantidad de bloqueo y bloqueo al intentar generar números.

Identidad existe por una razón, lo utilizan.

Cuando SQL Denali sale apoyará secuencias que serán más eficientes que los de identidad, pero no se puede crear algo más eficiente a sí mismo.

Como para mover los registros de un ambiente a otro, ya sea convertir IDENTITY_INSERT SOBRE al hacer la inserción, o marcar la casilla en SSIS.

Answer 3

La columna de identidad suena bien para mí. No estoy seguro de entender la lógica de por qué es difícil de mover datos entre servidores.

Si desea que cada fila para tener una identidad única a nivel mundial se puede utilizar un UUID pero yo no lo haría a menos que esté seguro de que la singularidad global es necesario - por lo general no lo es. El uso de UUID como identificadores de que disminuya el rendimiento, los requisitos de espacio en disco aumentar y hacer la depuración más difícil -. Debido a la longitud que es difícil recordar un UUID, dilo a alguien por teléfono o escribir en un papel sin error

Answer 4

Para los ID numéricos simples, sólo tiene que ir con la identidad y olvidar todos los problemas de generar manualmente.

Siempre se puede crear una "mesa super" que utiliza una identidad como la PK y tienen una columna de tipo, y cualquier otra información. Cuando se necesita un nuevo ID (suponiendo que decir IDS únicos a través de diferentes tablas) acaba de insertar en esta tabla y agarrar el SCOPE_IDENTITY() y luego insertar en la tabla real que necesita.

Básicamente se crea una tabla: MasterIDs con una PK identidad, cuando se necesita para insertar una fila en el Cuadro 1, INSERT INTO MasterIDs y obtener la identidad generada por esa fila usando SCOPE_IDENTITY() y luego se insertan en Tabla 1 utilizando ese valor como el PK.

Tabla 1 tendrá un no-identidad int PK. Se podría hacer el mismo proceso para insertar en la Tabla2, etc. Let SQL Server gestionar los valores de identidad en el Mesa MasterIDs, que luego se puede utilizar en sus otras tablas. MasterIDs podría contener otras tablas, como el tipo (por lo que podría saber qué tabla, Tabla 1 o Tabla 2, etc., usos dicho valor de identidad.

Answer 5

Mientras asyou están utilizando las restricciones de clave externa correctamente (en cascada, actualización, etc), entonces usted va a estar bien con el uso de un campo de identidad. Realmente no veo una ventaja a la otra solución en este caso.

Answer 6

La identidad se hizo para adaptarse a su situación. Dispone de herramientas como la replicación para Exchange Server / entornos de datos que mantienen todo junto.

Answer 7

acabo de terminar una pieza de trabajo en el que he sustituido una columna identity SQL Server con un campo int normal y controlada asignación Id mí mismo.

he visto mejoras de rendimiento bastante impresionantes. A diferencia de la OP, no tengo una UDF para generar el id. Pero el principio es más o menos la misma: No forma parte del software que mantiene un grupo de id. Cuando se les acaba se pone otro lote mediante la consulta de la base de datos para la siguiente Baja valor y los incrementos esto al siguiente Alta .

Esto nos permite generar las identificaciones y relacionar todas las entidades fuera de una transacción en nuestro ORM antes de presentar los lotes a la base de datos y también sometemos lotes más grandes sin ida y vuelta extra para conseguir la identidad acaba de insertar (requerido por las columnas de identidad).

En la tabla Identificación tenemos hay más de una fila, que nos permite utilizar rangos específicos si lo deseamos. es decir, para la reutilización de bloques borrados y las identificaciones negativas.

Answer 8

He estado usando la identidad durante años y considerando seriamente la sustitución número de identidad con UNIQUEIDENTIFIER. Es una pesadilla cuando es necesario cambiar el tipo de datos si alguien lo ha diseñado para ser una base de datos compacta y pesadilla si es necesario agregar la identidad de una columna, también, no se puede actualizar la columna de identidad. Imagine que pone un int y su base de datos crece más allá de 2 mil millones de registros, de nuevo pesadilla para el cambio (considere FKs)! Cambiar nada con la identidad es una pesadilla y no es la escala de usar a menos que poner bigint! UNIQUEIDENTIFIER vs Identidad = comodidad y solidez frente a la mejora del rendimiento tal vez notable (no hizo el punto de referencia).

Actualización: Después de que he visto este definitivamente me inclino hacia UNIQUEIDENTIFIER. Esto demuestra ningún beneficio real de la identidad bigint y un montón de beneficios para UNIQUEIDENTIFIER! Diferentes versiones de SQL Server podrían tener un resultado diferente. No es sólo la belleza de sentir una identificación única a través de todas las bases de datos y sistemas (robustez)! Mover, copiar, transformar los datos a su gusto! https://www.mssqltips.com / sqlservertip / 5105 / sql-server-rendimiento en comparación-int-contra-GUID /