Oracle ссылочной целостности против диапазона данных в ПК таблицы

Question

Рассмотрим следующую конструкцию:

LEGAL_CASE table (columns) 
-------------------------------- 
LEGAL_CASE_ID 
APPELLATE_CRT_ID 
DISTRICT_CRT_ID 
TRIAL_CRT_ID 

со всеми судами определяется в таблице поиска

COURT table (data) 
-------------------------------------------- 
CRT_ID  CRT_TYPE  CRT_NAME 
-------------------------------------------- 
1   A    APPELLATE COURT 1 
2   A    APPELLATE COURT 2 
3   D    DISTRICT COURT 1 
4   D    DISTRICT COURT 2 
5   T    TRIAL COURT 1 
6   T    TRIAL COURT 2 

Стандартный способ сделать это, я полагаю, было бы иметь отдельную таблицу поиска для каждого типа суда, но я предпочитаю сбрасывать их все в одном под разными кодами, для компактности и элегантности. Таким образом, я хотел бы иметь некоторую форму ограничения ссылочной целостности (если выше это исключает FK), который обеспечит, что все, что может войти в APPELLATE_CRT_ID, - это значения CRT_ID из таблицы COURT , но только там, где CRT_TYPE = 'A' и т. Д. . Регулярный FK позволял бы Ds и Ts, но я хотел бы сделать его более ограничительным.

Есть ли способ сформулировать FK, который ограничивал бы диапазон значений в таблице первичных ключей, или я должен просто перейти с RULE или другим типом CONSTRAINT?

Answer 1

Если вы хотите иметь ссылочную целостность с учетом этой таблицы поиска, вам необходимо добавить несколько столбцов CRT_TYPE в таблицу legal_case и включить их как часть внешнего ключа. Что-то вроде

CREATE TABLE legal_case (
    legal_case_id  integer primary key, 
    appellate_crt_id integer, 
    appellate_crt_type varchar2(1), 
    district_crt_id integer, 
    district_crt_type varchar2(1), 
    ... 
    constraint fk_appelate_crt foreign key (appelate_crt_id, appellate_crt_type) references court(crt_id, crt_type), 
    constraint fk_district_crt foreign key (district_crt_id, district_crt_type) references court(crt_id, crt_type), 
    ... 
); 

Конечно, это потребовало бы, что первичный ключ (или ограничение уникальности, хотя я не люблю внешние ключи, которые ссылаются на нно-первичные ключи) из court таблицы будет crt_id, crt_type, а не просто crt_id.

В противном случае вы будете искать триггеры для проверки такого рода вещей (что становится довольно болезненным, если вы хотите предотвратить сеанс A от изменения строки court, в то время как сеанс B имеет незафиксированные изменения, которые зависят от существующего состояния эта строка) или, возможно, создание материализованного представления с соответствующим набором ограничений, которые объединяли данные из этих двух таблиц.