Указать внешний ключ на одном столбце, а значение другого столбца

Question

У меня есть таблица ASSETS, которая имеет структуру, как показано ниже:

---------------------------------------------------- 
ID (PK) | DESCRIPTION | TYPE | Do- | Do+ | Dx- | Dx+ 
---------------------------------------------------- 

TYPE столбца имеет внешних ключ, возможные значения SECURITY или CURRENCY (т.е. FX), а также у меня есть еще две таблицы: CURRENCIES (, например, EUR, RUB или USD):

-------------------------------------------------------- 
ID (PK)| FROM (FK ASSETS.ID) | TO (FK ASSETS.ID) | VALUE 
-------------------------------------------------------- 

и SECURITIES (, например, MTS, GAZP или VTB):

---------------------------------------------------------- 
ID (PK)(FK ASSETS.ID)| CURRENCY (PK)(FK ASSETS.ID) | VALUE 
---------------------------------------------------------- 

Как я могу сделать ограничение, что не только действует как внешний ключ в CURRENCIES.FROM, CURRENCIES.TO и SECURITIES.CURRENCY, но также проверяет, соответствует ли ссылка ASSETS.TYPECURRENCY, а также в SECURITIES также проверяет, относится ли ссылка ASSETS.TYPE для SECURITIES.ID является SECURITY?

Возможно, я могу написать триггеры для проверки значения ASSETS.TYPE, но я ищу другое решение прямо сейчас (если возможно, конечно).

Если есть лучшие способы сделать то, что нужно (как лучший дизайн базы данных), пожалуйста, поделитесь своими идеями.

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

Answer 1

Ответ на исходный вопрос заключается в использовании дополнительного CHECKограничения как:

CREATE TABLE CURRENCIES (
    ... 
    CONSTRAINT c_asset_from CHECK(exists(select 1 from ASSETS a where a.id = from and a.type = 'CURRENCY')) 
); 

И подобный constraion для TO поля и в SECURITIES для CURRENCY области.
Но я думаю, что ваш новый дизайн, с отдельными FK для security и currency, лучший дизайн.

Answer 2

Вы можете использовать чеки для этого. Вы хотите жестко установить эти значения?

CREATE TABLE Persons 
(
    P_Id int NOT NULL, 
    LastName varchar(255) NOT NULL, 
    FirstName varchar(255), 
    Address varchar(255), 
    City varchar(255), 
    CONSTRAINT chk_Person CHECK (P_Id>0 AND City='Sandnes') 
) 

Источник: W3schools

И Using Firebird, может потребоваться иной синтаксис. Взгляните: Firebird reference

Answer 3

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

Вот план:

Посмотрите, как ASSET.ASSET_TYPE распространяется через обе «ветви», только чтобы быть объединены в SECURITY.ASSET_TYPE.

С SECURITY.ASSET_TYPE - это только одно поле, одно из SECURITY строка никогда не может подключаться к нескольким типам активов. Сказать немного по-другому: если ASSET и CURRENCY подключены к тому же SECURITY, они должны иметь одинаковые ASSET_TYPE.

В дополнение к этому, CURRENCY никогда не может указывать на ASSET s различного типа.

При необходимости вы можете вернуть старые ключи суррогата (и другие поля) в эту модель.

---

Это, как говорится, генерируя ASSET_NO представляет некоторые проблемы.

• Вы можете просто использовать auto-incrementing механизм встроенного в ваш DBMS, но что бы оставить «дыру» (то есть два различных типа актива никогда не будет использовать то же целое число, даже если они технически возможно).
• Или вы можете найти следующее значение вручную, но в этом случае вам придется обрабатывать параллелизм (либо сериализовать вставки с помощью блокировки, либо вставить повторную попытку, если одновременная транзакция пробовала одно и то же значение).

Answer 4

IMO технически проект может быть подвергнут критике в двух категориях:

• Имея двойного назначения внешнего ключа в таблице активов называется type (Polymorphic Association anti-pattern).
  Это будет нарушать первую нормальную форму (атомный вопрос), теряя ссылочную целостность.
  Решение может быть упрощение взаимосвязи по наследованию.
  Имея базу таблица для таблиц валюты и безопасности под названием Money, содержащая совместно используемые им свойства, например name.
  Первичный ключ денежной таблицы будет первичным ключом Currency и Security таблиц.
  Наличие внешнего ключа Money внутри Asset будет решением.
• Использование surrogate identifier на таблицах активов, которые приведут Потеря бизнес-логики в схеме.
  Я предпочту иметь составной первичный ключ в таблице активов PK{ID, TYPE(money fk)}.
  Затем с контрольные ограничения на CURRENCIES и SECURITIES решить проблему .
  CURRENCIES_chk {FK.CURRENCY = FK_TO.Money && FK.CURRENCY = FK_FROM.Money} SECURITIES_chk {FK.SECURITY = FK.Money}