¿Cuándo tener una columna de identidad no es una buena idea?

Question

En las tablas donde solo necesita 1 columna como clave, y los valores en esa columna pueden ser enteros, cuando no debe usar un campo de identidad?

Por el contrario, en la misma tabla y columna, ¿cuándo generaría manualmente sus valores y no usaría un valor autogenerado para cada registro?

Supongo que sería el caso cuando hay muchas inserciones y elimina en la tabla. ¿Estoy en lo cierto? ¿Qué otras situaciones podrían ser?

Answer 1

Si ya se estableció en el lado sustituto de Great Primary Key Debacle, entonces no puedo encontrar una sola razón para no usar las claves de identidad. Las alternativas habituales son guids (tienen muchas desventajas, principalmente de tamaño y aleatoriedad) y claves generadas por la capa de aplicación. Pero crear una clave sustituta en la capa de aplicación es un poco más difícil de lo que parece y tampoco cubre el acceso a datos no relacionados con la aplicación (es decir, cargas por lotes, importaciones, otras aplicaciones, etc.). El único caso especial son las aplicaciones distribuidas cuando las guías e incluso las guías secuenciales pueden ofrecer una mejor alternativa a las claves de identificación de sitios +.

Answer 2

Supongo que si está creando una tabla de enlaces muchos a muchos, donde ambos campos son foreign keys, no necesita un campo de identidad.

Actualmente, me imagino que la mayoría de ORMs esperan que exista un campo de identidad en cada tabla. En general, es una buena práctica proporcionar uno.

Answer 3

Puede no (normalmente) especificar valores al insertar en las columnas de identidad, por lo que por ejemplo, si la columna "ID" se especifica como una identificar el siguiente código SQL fallaría:

INSERT INTO MyTable (id, name) VALUES (1, 'Smith') 

Para llevar a cabo este tipo de inserción necesita tener IDENTITY_INSERT activado para esa tabla; esto no está destinado a ser normalmente y solo puede estar activo durante un máximo de 1 tabla en la base de datos en cualquier momento.

Answer 4

No estoy seguro de entender lo suficiente sobre su contexto, pero interpreto que su pregunta es:

"Si necesito que la base de datos cree una columna única (por el motivo que sea), ¿cuándo no debería ser una columna de entero (identidad) monótonamente creciente?"

En esos casos, no hay ninguna razón para usar otra cosa que no sea la instalación proporcionada por el DBMS para este propósito; en su caso (SQL Server?) eso es una identidad.

Excepto:

Si lo que necesitas para combinar la tabla con datos de otra fuente, utilizar un GUID, lo que evitará duplicados de las llaves de la colisión.

Answer 5

Si necesita fusionar bases de datos, es mucho más fácil si no tiene que regenerar las claves.

Answer 6

Si necesito un sustituto, utilizaría una columna de IDENTIDAD o una columna GUID según la necesidad de exclusividad global.

Si hay una clave primaria natural, o la clave principal se define como una combinación única de otras claves externas, entonces normalmente no tengo una IDENTIDAD ni la uso como clave principal.

Hay una excepción, que son las tablas de configuración de instantáneas que estoy siguiendo con un disparador de auditoría. En este caso, generalmente hay una "clave principal" lógica (generalmente la fecha de la instantánea y la clave natural de la fila, como un centro de costo o un número de cuenta gl para el cual la fila es un registro de configuración), pero en lugar de usar el "clave principal" como la clave principal, agrego una IDENTIDAD y la hago la clave principal y hago un índice o restricción único sobre la fecha y la clave natural. Aunque teóricamente la fecha y la clave natural no deberían cambiar, en estas tablas, si un usuario hace eso en lugar de agregar una nueva fila y eliminar la anterior, quiero la auditoría (que refleja un cambio en una fila identificada por su clave principal)) para reflejar realmente un cambio en la fila, no la desaparición de una clave y la aparición de una nueva.

Answer 7

Un caso de no querer un campo de identidad estaría en una relación de uno a uno. La tabla secundaria tendría como clave principal el mismo valor que la tabla principal. La única razón para tener un campo de identidad en esa situación parece ser satisfacer un ORM.

Answer 8

Recientemente implementé un sufijo Trie en C# que podría indexar novelas, y luego permitir que las búsquedas se realicen de manera extremadamente rápida, lineal al tamaño de la cadena de búsqueda. Parte de los requisitos (esta era una tarea) era usar almacenamiento sin conexión, así que usé MS SQL y necesitaba una estructura para representar un Nodo en una tabla.

Terminé con la siguiente estructura: NodeID Character ParentID, etc., donde el NodeID era una clave principal.

No quería que esto se hiciera como una identidad autoincrementing por dos razones principales.

1. ¿Cómo obtengo el valor de un NodeID después de agregarlo a la base de datos/tabla de datos?
2. Quería más control a la hora de generar mis propios ID.