Существуют ли в каких-либо СУБД такое понятие, как условный уникальный индекс?

Question

[Иван Мельников]

Условный уникальный индекс мог бы:
1) обеспечивать уникальность значений в поле для каждого уникального значения в соседнем поле таблицы (решение: составной уникальный индекс);
2) обеспечивать уникальность значений в поле для каждого уникального значения каком-то поле родительской таблицы.
Например, имеются две таблицы:

Мне нужно обеспечить уникальность поля addr в таблице Line, но не просто уникальность (адреса в разных городах могут же совпадать), а уникальность для каждого уникального значения в поле city_id таблицы Group. Это возможно?

Comments

[zhaar]

Делается наборый индекс из нескольких полей (первые два из примера ниже) и ставится unique.
Если указано 2 поля, то можно будет создать только записи так:
1 - 1 - текст
1 - 2 - текст
2 - 1 - текст
2 - 2 - текст

А вот если после первичной вставки попытаешься вставить 1 - 1 - текст1, то SQL выдаст ошибку, что такая запись уже существует.

[Иван Мельников]

zhaar, это все понятно. Но поля-то в разных таблицах. См. мой вопрос.

Answer 1

[Decadal]

Вы можете сделать Composite Unique Key по полям addr, city_id или addr и group_id
Например:

ALTER TABLE Line ADD UNIQUE KEY `uk_address_city` (addr, group_id);

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

Comments

[Иван Мельников]

Вы можете сделать Composite Unique Key по полям addr, city_id

Я не понял, как я могу создать по этим полям Composite Unique Key, если эти поля находятся в разных таблицах.

[Decadal]

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

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