¿Puedo agregar una restricción única que ignore las violaciones existentes?

Tengo una tabla que actualmente tiene valores duplicados en una columna.

No puedo eliminar estos duplicados erróneos, pero me gustaría evitar que se agreguen valores adicionales no únicos.

¿Puedo crear uno UNIQUEque no verifique el cumplimiento existente?

He intentado usar NOCHECKpero no tuve éxito.

En este caso, tengo una tabla que vincula la información de licencia a "CompanyName"

EDITAR: Tener varias filas con el mismo "CompanyName" son datos incorrectos, pero no podemos eliminar o actualizar esos duplicados en este momento. Un enfoque es hacer que los INSERTs utilicen un procedimiento almacenado que fallará para los duplicados ... Si fuera posible que SQL verificara la unicidad por sí mismo, sería preferible.

Estos datos se consultan por el nombre de la empresa. Para los pocos duplicados existentes, esto significará que se devuelven y muestran varias filas ... Si bien esto es incorrecto, es aceptable en nuestro caso de uso. El objetivo es prevenirlo en el futuro. Me parece por los comentarios que tengo que hacer esta lógica en los procedimientos almacenados.

La respuesta es sí". Puede hacerlo con un índice filtrado (consulte aquí la documentación).

Por ejemplo, puedes hacer:

create unique index t_col on t(col) where id > 1000;

Esto crea un índice único, solo en filas nuevas , en lugar de en las filas antiguas. Esta formulación particular permitiría duplicados con valores existentes.

Si solo tiene un puñado de duplicados, puede hacer algo como:

create unique index t_col on t(col) where id not in (<list of ids for duplicate values here>);

Si tu puedes hacerlo.

Aquí hay una tabla con duplicados:

CREATE TABLE dbo.Party
  (
    ID INT NOT NULL
           IDENTITY ,
    CONSTRAINT PK_Party PRIMARY KEY ( ID ) ,
    Name VARCHAR(30) NOT NULL
  ) ;
GO

INSERT  INTO dbo.Party
        ( Name )
VALUES  ( 'Frodo Baggins' ),
        ( 'Luke Skywalker' ),
        ( 'Luke Skywalker' ),
        ( 'Harry Potter' ) ;
GO

Ignoremos los existentes y asegurémonos de que no se puedan agregar nuevos duplicados:

-- Add a new column to mark grandfathered duplicates.
ALTER TABLE dbo.Party ADD IgnoreThisDuplicate INT NULL ;
GO

-- The *first* instance will be left NULL.
-- *Secondary* instances will be set to their ID (a unique value).
UPDATE  dbo.Party
SET     IgnoreThisDuplicate = ID
FROM    dbo.Party AS my
WHERE   EXISTS ( SELECT *
                 FROM   dbo.Party AS other
                 WHERE  other.Name = my.Name
                        AND other.ID < my.ID ) ;
GO

-- This constraint is not strictly necessary.
-- It prevents granting further exemptions beyond the ones we made above.
ALTER TABLE dbo.Party WITH NOCHECK
ADD CONSTRAINT CHK_Party_NoNewExemptions 
CHECK(IgnoreThisDuplicate IS NULL);
GO

SELECT * FROM dbo.Party;
GO

-- **THIS** is our pseudo-unique constraint.
-- It works because the grandfathered duplicates have a unique value (== their ID).
-- Non-grandfathered records just have NULL, which is not unique.
CREATE UNIQUE INDEX UNQ_Party_UniqueNewNames ON dbo.Party(Name, IgnoreThisDuplicate);
GO

Probemos esta solución:

-- cannot add a name that exists
INSERT  INTO dbo.Party
        ( Name )
VALUES  ( 'Frodo Baggins' );

Cannot insert duplicate key row in object 'dbo.Party' with unique index 'UNQ_Party_UniqueNewNames'.

-- cannot add a name that exists and has an ignored duplicate
INSERT  INTO dbo.Party
        ( Name )
VALUES  ( 'Luke Skywalker' );

Cannot insert duplicate key row in object 'dbo.Party' with unique index 'UNQ_Party_UniqueNewNames'.


-- can add a new name 
INSERT  INTO dbo.Party
        ( Name )
VALUES  ( 'Hamlet' );

-- but only once
INSERT  INTO dbo.Party
        ( Name )
VALUES  ( 'Hamlet' );

Cannot insert duplicate key row in object 'dbo.Party' with unique index 'UNQ_Party_UniqueNewNames'.

El índice único filtrado es una idea brillante, pero tiene una desventaja menor, no importa si usa la WHERE identity_column > <current value>condición o el WHERE identity_column NOT IN (<list of ids for duplicate values here>).

Con el primer enfoque, aún podrá insertar datos duplicados en el futuro, duplicados de datos existentes (ahora). Por ejemplo, si tiene (incluso una) fila ahora con CompanyName = 'Software Inc.', el índice no prohibirá la inserción de una fila más con el mismo nombre de la compañía. Solo lo prohibirá si lo intentas dos veces.

Con el segundo enfoque hay una mejora, lo anterior no funcionará (lo cual es bueno). Sin embargo, aún podrá insertar más duplicados o duplicados existentes. Por ejemplo, si tiene (dos o más) filas ahora con CompanyName = 'DoubleData Co.', el índice no prohibirá la inserción de una fila más con el mismo nombre de la compañía. Solo lo prohibirá si lo intentas dos veces.

(Actualización) Esto se puede corregir si por cada nombre duplicado, se mantiene fuera de la lista de exclusión un ID. Si, como en el ejemplo anterior, hay 4 filas con duplicados CompanyName = DoubleData Co.e ID 4,6,8,9, la lista de exclusión debe tener solo 3 de estos ID.

Con el segundo enfoque, otra desventaja es la condición engorrosa (cuánto engorroso depende de cuántos duplicados hay en primer lugar), ya que SQL-Server parece no admitir el NOT INoperador en la WHEREparte de los índices filtrados. Ver SQL-Fiddle . En lugar de eso WHERE (CompanyID NOT IN (3,7,4,6,8,9)), tendrá que tener algo así como WHERE (CompanyID <> 3 AND CompanyID <> 7 AND CompanyID <> 4 AND CompanyID <> 6 AND CompanyID <> 8 AND CompanyID <> 9)no estoy seguro si hay implicaciones de eficiencia con tal condición, si tiene cientos de nombres duplicados.

Otra solución (similar a la de @Alex Kuznetsov) es agregar otra columna, llenarla con números de rango y agregar un índice único que incluya esta columna:

ALTER TABLE Company
  ADD Rn TINYINT DEFAULT 1;

UPDATE x
SET Rn = Rnk
FROM
  ( SELECT 
      CompanyID,
      Rn,
      Rnk = ROW_NUMBER() OVER (PARTITION BY CompanyName 
                               ORDER BY CompanyID)
    FROM Company 
  ) x ;

CREATE UNIQUE INDEX CompanyName_UQ 
  ON Company (CompanyName, Rn) ; 

Luego, la inserción de una fila con nombre duplicado fallará debido a la DEFAULT 1propiedad y al índice único. Esto todavía no es 100% infalible (mientras que Alex lo es). Los duplicados seguirán apareciendo si Rnse establece explícitamente en la INSERTdeclaración o si los Rnvalores se actualizan maliciosamente.

SQL-Fiddle-2

Otra alternativa es escribir una función escalar que verifique si ya existe un valor en la tabla y luego llamar a esa función desde una restricción de verificación.

Esto hará cosas horribles para el rendimiento.

Estoy buscando lo mismo: cree un índice único no confiable para que se ignoren los datos incorrectos existentes, pero los nuevos registros no pueden ser duplicados de nada que ya exista.

Mientras leo este hilo, se me ocurre que una mejor solución es escribir un disparador que verifique [insertado] en la tabla principal para ver si hay duplicados, y si existen duplicados entre esas tablas, ROLLBACK TRAN.