Bases de datos: Usar Identidad o no?

A primera vista, parece que no hay nada especial para considerar antes de usar la propiedad de columna IDENTITY, el mecanismo de la numeración automática de SQL Server. Pero sobre todo en entornos de gran tamaño puede ser vital, primero hay que comprender algunas de las funciones de Identity y algunas de sus limitaciones. En algunos casos, es posible que prefiera utilizar su propio mecanismo de numeración automática. para ayudarnos a decidir sobre el mejor sistema, voy a proporcionar algunos datos sobre la identidad, discutir algunas de sus limitaciones, y mostrar dos alternativas.

Fundamentos de la IDENTIDAD

Aquí hay algunas cosas que usted debe saber sobre la propiedad IDENTITY:

• Es posible utilizar IDENTIDAD no sólo con los números enteros, pero también con cualquier tipo de datos numéricos que tiene una escala de 0. Esta es una buena cosa, especialmente cuando se necesita para apoyar a los números más grandes que la cantidad de datos que puede contener. El valor entero (INT) tiene una capacidad de 2,147,483,647 registros, y el valor de gran entero (BIGINT) tiene una capacidad de 9,223,372,036,854,775,807 registros.
• IDENTIDAD, combinado con una restricción PRIMARY KEY o UNIQUE, le permite proporcionar un identificador único de la fila de manera sencilla, sin la necesidad de supervisarlo. SQL Server hace el trabajo por sí solo.
• A diferencia de la función de secuencia de Oracle, SQL Server no proporciona un mecanismo de secuenciación independiente. En cambio, la secuencia proporcionada por la propiedad IDENTITY se aplica a una sola tabla. Cuando usted necesita un mecanismo de secuenciación que genera números para su uso en las tablas, como diferentes, por ejemplo, con teclas que no deben superponerse a través de tablas, querrá elegir una alternativa a la identidad. Esto es una metodología muy dada en los usuarios de Oracle.
• La propiedad IDENTITY y la columna a la que está asociado son inseparables, lo que significa que no se puede agregar o quitar de identidad de una columna durante la existencia de los datos. Se puede cambiar esta configuración ya con datos, pero el cambio puede ser muy lento, sobre todo con tablas grandes. Por ejemplo, para dar identidad a una columna existente, puede crear una tabla nueva, copiar los datos de la tabla original, eliminar la tabla original, y luego dar la nueva tabla el mismo nombre. También se puede utilizar un proceso similar para retirar de identidad de una columna existente. En ambos casos, estas actividades requieren que la tabla esté fuera de servicio, tiempo que puede ser muy largo para las tablas grandes o con muchos registros.
• Cuando se utiliza una instrucción INSERT en una tabla que tiene una columna IDENTITY, el valor de identidad aumenta si el INSERT tiene éxito o fracasa, incluso si se produce un error en una clave principal o CHECK violación de restricción. Si una transacción se revierte, ya sea implícita o explícitamente, el valor de la identidad en esa columna no se revierte, por lo que podría terminar con las lagunas en la secuencia, incluso cuando usted no va a eliminar todas las filas. Esto puede ser un problema cuando se está creando secuencias que no pueden contener espacios, tales como los números de factura.
• No se puede actualizar vistas particionadas que se basan en tablas que tienen una columna IDENTITY.
• La sentencia TRUNCATE TABLE restablece la propiedad de IDENTIDAD en la tabla a manipular. Para conservar el contador de identidad, utilice DELETE en lugar de TRUNCATE TABLE, pero tenga en cuenta que DELETE es mucho más lento porque se registra por completo.

El asunto es que una tabla puede existir con y sin IDENTITY, y en ambos casos se puede almacenar registro, editarlos, borrar y actualizar. Pero realmente es el perfil del proyecto el que determina su uso o no.

En qué escenarios es recomendable o no el uso de IDENTITY en una columna.

Es recomendable usar IDENTITY cuando:

• Nuestra cantidad de registros no dependa de la capacidad del tipo de campo. Es decir, si el proyecto no implica hacer uso de todos y cada uno de los números generados en la secuencia y podemos ser holgados en su contenido.
• Se manejan proyectos modulares en constante cambio y crecimiento. Esto facilita el entorno de desarrollo y permite la confianza de tener políticas claras con respecto al manejo de la base de datos.
• Pueden haber cargas transaccionales de consultas complejas.
• El rendimiento del software se vea afectado.
• Se requiera de mayor escalabilidad.

No es recomendable usar IDENTITY cuando:

• El valor del IDENTITY es crítico: numeración de facturas, secuencias de inventarios, comprobantes de pago.
• La carga transaccional es muy intensa y concurrente desde diferentes escenarios para las operaciones de INSERT y DELETE.
• No hay control absoluto de la base de datos.

¿Cómo se configura en SQL Server?

Para modificarlo, ingresamos la definición de la tabla y seleccionamos el campo numérico que queremos cambiarle la propiedad:

Por instrucciones de SQL, hay que tener en cuenta que debe hacerlo al momento de crear la tabla:

CREATE TABLE nombredemitabla
    (
    IdPersona int NOT NULL IDENTITY (1, 1)
    )  ON [PRIMARY]
GO

Sin IDENTITY:

CREATE TABLE nombredemitabla
    (
    IdPersona int NOT NULL
    )  ON [PRIMARY]
GO