Проверка уникального значения sql с ограничением

Вы можете создать индексированное представление, которое будет поддерживать ваше ограничение на сохранение уникальности ID для [Status] = 1.

create view dbo.v_YourTable with schemabinding as
select ID
from dbo.YourTable
where [Status] = 1

go

create unique clustered index UX_v_UniTest_ID on v_YourTable(ID)

В SQL Server 2008 вместо этого можно было использовать уникальный отфильтрованный индекс.

Если в таблице могут быть повторяющиеся значения ID, то проверочное ограничение не подойдет для вашей ситуации. Я думаю, что единственный способ - использовать триггер. Если вы ищете пример, я могу опубликовать его. Но в целом используйте триггер, чтобы проверить, имеет ли вставленный/обновленный идентификатор статус 1, который дублируется для одного и того же идентификатора.

EDIT: вы всегда можете использовать уникальное ограничение для ID и Value. Я думаю, это даст вам то, что вы ищете.

Вы можете поместить это в триггер вставки/обновления, чтобы убедиться, что существует только одна комбинация со значением 1; если ваше условие не выполняется, вы можете выдать перехватываемую ошибку и заставить операцию откатиться.

Если вы можете использовать NULL вместо 0 для нулевого статуса, то вы можете использовать ограничение UNIQUE для пары, и это должно работать. Поскольку NULL не является фактическим значением (NULL != NULL), строки с несколькими значениями NULL не должны конфликтовать.

ИМХО, это в основном проблема нормализации. Столбец с именем «id» не имеет однозначного адреса строки, поэтому он никогда не может быть PK. Необходим как минимум новый (суррогатный) ключ (элемент). Само ограничение не может быть выражено как выражение «внутри строки», поэтому оно должно быть выражено в терминах FK.

Таким образом, он разбивается на две таблицы: одна с PK = id и FK REFERENCING two.sid

Два с суррогатным ключом PK= и идентификатором FK ССЫЛКА на one.id Исходное «значение» полезной нагрузки также находится здесь.

«Однобитовая переменная» исчезает, потому что ее можно выразить в терминах СУЩЕСТВУЕТ. (фактически таблица one указывает на строку, содержащую токен)

[Я ожидаю, что система правил Postgres может использоваться для использования вышеупомянутой модели с двумя таблицами для эмуляции предполагаемого поведения OP. Но это был бы уродливый взлом...]

РЕДАКТИРОВАТЬ/ОБНОВИТЬ:

Postgres поддерживает частичные/условные индексы. (не знаю о ms-sql)

DROP TABLE tmp.one;
CREATE TABLE tmp.one
    ( sid INTEGER NOT NULL PRIMARY KEY -- surrogate key
    , id INTEGER NOT NULL
    , status INTEGER NOT NULL DEFAULT '0'
    /* ... payload */
    );
INSERT INTO tmp.one(sid,id,status) VALUES
  (1,1,0) , (2,1,1) , (3,1,0)
, (4,2,0) , (5,2,0) , (6,2,1)
, (7,3,0) , (8,3,0) , (9,3,1)
  ;

CREATE UNIQUE INDEX only_one_non_zero ON tmp.one (id)
    WHERE status > 0 -- "partial index" 
    ;

\echo this should succeed
BEGIN ;
UPDATE tmp.one SET status = 0 WHERE sid=2;
UPDATE tmp.one SET status = 1 WHERE sid=1;
COMMIT;

\echo this should fail
BEGIN ;
UPDATE tmp.one SET status = 1 WHERE sid=4;
UPDATE tmp.one SET status = 0 WHERE sid=9;
COMMIT;

SELECT * FROM tmp.one ORDER BY sid;

я придумал решение

Сначала создайте функцию

CREATE FUNCTION [dbo].[Check_Status] (@ID int)
RETURNS INT
AS
BEGIN
 DECLARE @r INT;
 SET @r =
  (SELECT SUM(status) FROM dbo.table where ID= @ID);
 RETURN @r;
END

Второе создание ограничения в таблице

([dbo].[Check_Status]([ID])<(2))

Таким образом, один идентификатор может иметь один статус (1) и как можно больше статусов (0).