ПРОВЕРЬТЕ ограничение на основе значения столбца В ДРУГОЙ таблице

Question

SqlServer

Предположим, у меня есть 2 таблицы:

Таблица 1 - с столбцом A

Таблица 2 - с столбцом B [Бит] Не ноль

Возможно ли иметь Проверочное ограничение, такое, что значение столбца B может быть «0», только если столбец A НЕ НЕДЕЙСТВИТЕЛЕН.

ИЛИ другими словами, значение столбца B может будет "1", только когда столбец A равен NULL.

Заранее спасибо.

Answer 1

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

Убедитесь, что вы прочитали до конца

Итак, если у нас есть:

CREATE TABLE Table1 (
    Table1ID char(5) not null,
    ColumnA int null,
    constraint PK_Table1 PRIMARY KEY (Table1ID)
)
CREATE TABLE Table2 (
    Table2ID char(7) not null,
    Table1ID char(5) not null,
    ColumnB bit not null,
    constraint PK_Table2 PRIMARY KEY (Table2ID),
    constraint FK_Table2_Table1 FOREIGN KEY (Table1ID) references Table1 (Table1ID)
)

Мы можем запустить этот скрипт:

alter table Table1 add
    ColumnBPrime as CAST(CASE WHEN ColumnA is NULL THEN 1 ELSE 0 END as bit) PERSISTED
go
alter table Table1 add constraint UQ_Table1_WithColumnBPrime UNIQUE (Table1ID, ColumnBPrime)
go
alter table Table2 add constraint FK_Table2_Table1_CheckColumnB FOREIGN KEY (Table1ID, ColumnB) references Table1 (Table1ID,ColumnBPrime)

Надеемся, вы увидите, как это обеспечивает связь между двумя таблицами ¹ .

---

Однако существует проблема . В T- SQL любой оператор DML может вносить изменения только в одну таблицу. Таким образом, нет способа выпустить обновление, которое одновременно изменяет, является ли ColumnA нулевым или нет , а меняет столбец B. в соответствии с ним.

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

---

¹ Теперь личное дело в том, удаляешь ли ты предыдущий внешний ключ или оставляешь его как «настоящий».