Посмотрите на это из модели pov. У вас есть две таблицы с одинаковым типом данных в каждом из них, предприятие компания. Единственная разница между ними - их роль или отношение к вашей компании. Так почему бы не держать их всех в одном ведре?
Companies:
ID code Name
-- ---- ---------
1 ABC ABC Corp
2 DEF DEF Corp
3 JHI JHI Inc.
Если конкретная компания может быть только клиент или носитель, что обозначение может быть помещен в компаний таблицы. Поскольку, очевидно, одна компания может быть обоим, обозначение переходит в отдельную таблицу. Ниже показано, что компания 1, «ABC», является клиентом («L») и перевозчиком («R»), компания 2 является только клиентом, а компания 3 является перевозчиком.
CompanyRoles:
CompanyID Type
--------- ----
1 'L'
1 'R'
2 'L'
3 'R'
Там нет необходимости хранить несколько копий одних и тех же данных, только потому, что компания может играть несколько ролей. Если есть данные, зависящие от ролей, данные, которые поддерживаются на клиенте, но не для носителей, или наоборот, то субтитры могут сохранить это.
Что касается контактов, если у компании есть один контакт независимо от роли, контактная информация может быть добавлена к . Компании стол. Если контакт зависит от роли, он добавляется в таблицу CompanyRoles.
CompanyRoles:
CompanyID Type ContactID
--------- ---- ---------
1 'L' 1
1 'R' 2
2 'L' 3
3 'R' 4
Хотите увидеть список клиентов?
select c.ID as ClientID, c.Code as ClientCode, c.Name as ClientName,
ci.ContactName
from Companies c
join CompanyRoles cr
on cr.CompanyID = c.ID
and cr.Type = 'L'
left join Contacts ct -- In case no contact is currently defined
on ct.ContactID = cr.ContactID
join ClientSpecificData csd
on csd.ClientID = c.ID;
Хотите увидеть список перевозчиков?
select c.ID as CarrierID, c.Code as CarrierCode, c.Name as CarrierName,
ci.ContactName
from Companies c
join CompanyRoles cr
on cr.CompanyID = c.ID
and cr.Type = 'R'
left join Contacts ct -- In case no contact is currently defined
on ct.ContactID = cr.ContactID
join CarrierSpecificData csd
on csd.ClientID = c.ID;
Вы можете создать представление о двух последних запросах, чтобы обеспечить единый источник данных для тех приложений, которые имеют дело только с клиентами или только перевозчиков. Триггеры на представлениях могут обрабатывать входящие операторы DML по мере необходимости, чтобы направлять данные в соответствующие таблицы.
Как вы можете видеть, запросы являются чистыми и простыми. Целостность данных проста и масштабируемость не является проблемой. Чего еще можно хотеть?
Каков желаемый результат, если два найденных совпадения не разрешены к одному и тому же 'contactID'? Что делать, если найден только один матч? –
В ссылке tbl они оба имеют контакт 1 – Damien
Что делать, если у одного был «контактID = 1», тогда как другой матч имел «contactID = 2», или этот случай не считается возможным? –