умовне унікальне обмеження

Question 1

У мене ситуація, коли мені потрібно застосувати унікальне обмеження для набору стовпців, але лише для одного значення стовпця.

Так, наприклад, у мене є така таблиця, як Table (ID, Name, RecordStatus).

RecordStatus може мати значення лише 1 або 2 (активне чи видалене), і я хочу створити унікальне обмеження для (ID, RecordStatus) лише тоді, коли RecordStatus = 1, оскільки мені все одно, чи є кілька видалених записів з однаковим Посвідчення особи.

Крім написання тригерів, чи можу я це зробити?

Я використовую SQL Server 2005.

Question 2

Додайте таке обмеження перевірки. Різниця полягає в тому, що ви повернете false, якщо Status = 1 і Count> 0.

http://msdn.microsoft.com/en-us/library/ms188258.aspx

CREATE TABLE CheckConstraint
(
  Id TINYINT,
  Name VARCHAR(50),
  RecordStatus TINYINT
)
GO

CREATE FUNCTION CheckActiveCount(
  @Id INT
) RETURNS INT AS BEGIN

  DECLARE @ret INT;
  SELECT @ret = COUNT(*) FROM CheckConstraint WHERE Id = @Id AND RecordStatus = 1;
  RETURN @ret;

END;
GO

ALTER TABLE CheckConstraint
  ADD CONSTRAINT CheckActiveCountConstraint CHECK (NOT (dbo.CheckActiveCount(Id) > 1 AND RecordStatus = 1));

INSERT INTO CheckConstraint VALUES (1, 'No Problems', 2);
INSERT INTO CheckConstraint VALUES (1, 'No Problems', 2);
INSERT INTO CheckConstraint VALUES (1, 'No Problems', 2);
INSERT INTO CheckConstraint VALUES (1, 'No Problems', 1);

INSERT INTO CheckConstraint VALUES (2, 'Oh no!', 1);
INSERT INTO CheckConstraint VALUES (2, 'Oh no!', 2);
-- Msg 547, Level 16, State 0, Line 14
-- The INSERT statement conflicted with the CHECK constraint "CheckActiveCountConstraint". The conflict occurred in database "TestSchema", table "dbo.CheckConstraint".
INSERT INTO CheckConstraint VALUES (2, 'Oh no!', 1);

SELECT * FROM CheckConstraint;
-- Id   Name         RecordStatus
-- ---- ------------ ------------
-- 1    No Problems  2
-- 1    No Problems  2
-- 1    No Problems  2
-- 1    No Problems  1
-- 2    Oh no!       1
-- 2    Oh no!       2

ALTER TABLE CheckConstraint
  DROP CONSTRAINT CheckActiveCountConstraint;

DROP FUNCTION CheckActiveCount;
DROP TABLE CheckConstraint;

Question 3

Ось, відфільтрований індекс . З документації (курсив мій):

Відфільтрований індекс - це оптимізований некластеризований індекс, який особливо підходить для охоплення запитів, які вибираються з чітко визначеної підмножини даних. Він використовує предикат фільтру для індексації частини рядків у таблиці. Добре розроблений відфільтрований індекс може покращити ефективність запитів, а також зменшити витрати на обслуговування індексу та зберігання порівняно з індексами з повною таблицею.

І ось приклад поєднання унікального індексу з предикатом фільтру:

create unique index MyIndex
on MyTable(ID)
where RecordStatus = 1;

Це, по суті, підтверджує унікальність того, IDколи RecordStatusє 1.

Після створення цього індексу порушення унікальності призведе до помилки:

Повідомлення 2601, рівень 14, стан 1, рядок 13
Не вдається вставити повторюваний рядок ключа в об’єкт „dbo.MyTable” з унікальним індексом „MyIndex”. Дублікат значення ключа (9999).

_{Примітка: відфільтрований індекс був представлений у SQL Server 2008. Для попередніх версій SQL Server див. Цю відповідь .}

Question 4

Ви можете перемістити видалені записи до таблиці, яка не має обмежень, і, можливо, скористатися поданням з таблицею UNION двох таблиць, щоб зберегти вигляд однієї таблиці.

Question 5

Ви можете зробити це по-справжньому хакі ...

Створіть подання для схеми на вашій таблиці.

СТВОРИТИ ПЕРЕГЛЯД Незалежно від SELECT * FROM Table WHERE RecordStatus = 1

Тепер створіть унікальне обмеження для подання з потрібними полями.

Однак одне примітка про подання схем, якщо ви зміните базові таблиці, вам доведеться відтворити подання. Багато причепів через це.

Question 6

Оскільки ви збираєтеся дозволити дублікати, унікальне обмеження не буде працювати. Ви можете створити обмеження перевірки для стовпця RecordStatus та збережену процедуру для INSERT, яка перевіряє наявні активні записи перед тим, як вставляти повторювані ідентифікатори.

Question 7

Якщо ви не можете використовувати NULL як RecordStatus, як запропонував Білл, ви можете поєднати його ідею з індексом на основі функцій. Створіть функцію, яка повертає NULL, якщо RecordStatus не є одним із значень, які ви хочете врахувати у своєму обмеженні (а RecordStatus - інакше), і створіть індекс над цим.

Це матиме ту перевагу, що вам не доведеться явно перевіряти інші рядки таблиці у вашому обмеженні, що може спричинити проблеми з продуктивністю.

Слід сказати, що взагалі не знаю SQL-сервера, але я успішно застосував цей підхід в Oracle.