versiones guia español descargar actualizar sql sql-server indexing constraints unique

sql - guia - ¿Cómo crear un índice único en una columna NULL?



qgis manual (4)

Estoy usando SQL Server 2005. Quiero restringir los valores en una columna para que sean únicos, mientras que permite NULLS.

Mi solución actual implica un índice único en una vista como esta:

CREATE VIEW vw_unq WITH SCHEMABINDING AS SELECT Column1 FROM MyTable WHERE Column1 IS NOT NULL CREATE UNIQUE CLUSTERED INDEX unq_idx ON vw_unq (Column1)

Alguna mejor idea?


Con SQL Server 2008, puede crear un índice filtrado: http://msdn.microsoft.com/en-us/library/cc280372.aspx . (Veo que Simon agregó esto como un comentario, pero pensó que se merecía su propia respuesta ya que el comentario es fácil de perder)

Otra opción es un disparador para verificar la unicidad, pero esto podría afectar el rendimiento.


El truco de columnas calculado es ampliamente conocido como un "nullbuster"; mis notas acreditan a Steve Kass:

CREATE TABLE dupNulls ( pk int identity(1,1) primary key, X int NULL, nullbuster as (case when X is null then pk else 0 end), CONSTRAINT dupNulls_uqX UNIQUE (X,nullbuster) )


Estrictamente hablando, una columna única anulable (o conjunto de columnas) puede ser NULA (o un registro de NULL) solo una vez, ya que tener el mismo valor (y esto incluye NULL) más de una vez obviamente viola la restricción única.

Sin embargo, eso no significa que el concepto de "columnas con nulos únicos" sea válido; para implementarlo realmente en cualquier base de datos relacional solo debemos tener en cuenta que este tipo de bases de datos están destinadas a ser normalizadas para funcionar adecuadamente, y la normalización generalmente implica la adición de varias tablas extra (sin entidad) para establecer relaciones entre las entidades .

Veamos un ejemplo básico considerando solo una "columna con anulación única", es fácil expandirla a más columnas.

Supongamos que la información representada por una tabla como esta:

create table the_entity_incorrect ( id integer, uniqnull integer null, /* we want this to be "unique and nullable" */ primary key (id) );

Podemos hacerlo separando uniqnull y agregando una segunda tabla para establecer una relación entre los valores uniqnull y the_entity (en lugar de tener uniqnull "inside" the_entity):

create table the_entity ( id integer, primary key(id) ); create table the_relation ( the_entity_id integer not null, uniqnull integer not null, unique(the_entity_id), unique(uniqnull), /* primary key can be both or either of the_entity_id or uniqnull */ primary key (the_entity_id, uniqnull), foreign key (the_entity_id) references the_entity(id) );

Para asociar un valor de uniqnull a una fila en the_entity necesitamos agregar una fila en the_relation.

Para las filas en the_entity donde no hay valores uniqnull están asociados (es decir, para los que pondríamos NULL en the_entity_incorrect) simplemente no agregamos una fila en the_relation.

Tenga en cuenta que los valores para uniqnull serán únicos para toda la relación, y también notará que para cada valor en la entidad no puede haber como máximo un valor en la relación, ya que las claves primaria y externa lo obligan.

Entonces, si se va a asociar un valor de 5 para uniqnull con un ID de the_entity de 3, necesitamos:

start transaction; insert into the_entity (id) values (3); insert into the_relation (the_entity_id, uniqnull) values (3, 5); commit;

Y, si un valor de id de 10 para the_entity no tiene una contraparte uniqnull, solo lo hacemos:

start transaction; insert into the_entity (id) values (10); commit;

Para desnormalizar esta información y obtener los datos que contendría una tabla como the_entity_incorrect, necesitamos:

select id, uniqnull from the_entity left outer join the_relation on the_entity.id = the_relation.the_entity_id ;

El operador "left outer join" asegura que todas las filas de the_entity aparecerán en el resultado, poniendo NULL en la columna uniqnull cuando no haya columnas coincidentes en the_relation.

Recuerde, cualquier esfuerzo realizado durante algunos días (o semanas o meses) en el diseño de una base de datos bien normalizada (y las correspondientes vistas y procedimientos de desnormalización) le ahorrará años (o décadas) de dolor y recursos desperdiciados.