Дизайн базы данных - ограничение связанных записей - PullRequest
Новая
       12

Дизайн базы данных - ограничение связанных записей

0 голосов
/ 21 марта 2012

В настоящее время у меня есть база данных со следующими отношениями:


Один клиент имеет несколько сущностей (через имя клиента - это уникально)
Один сущность имеет несколько служб EntityServices (через идентификатор сущности)
Одна служба имеет несколько EntityServices (через имя службы - в основном, таблицу служебных линий)

Теперь все это работает нормально, но я хочу создать таблицу с именем EngagementLetters.Он должен иметь следующие отношения:


Один клиент имеет несколько EngagementLetters (через имя клиента)
Один EngagementLetters имеет несколько EntityServices (через идентификатор письма об участии)
и хитрый: все EntityServicesпод одним EngagementLetter должен быть один и тот же клиент

Я смог создать вышеописанное, за исключением последнего пункта.Это поставило меня в тупик, я понятия не имею, как это сделать!Кто-нибудь сможет помочь с этим?


Приветствия,
Андрей

1 Ответ

2 голосов
/ 21 марта 2012 
      Client
     ^      ^
     |      |
     |      Entities   Service
     Eletter      ^          ^
        ^         |          |
        |_______ EntityServices

Как это?

"Один клиент имеет несколько EngagementLetters (через имя клиента - это уникально)"

почему имя клиента?Вы использовали Client Id для отношений с сущностью.Можно сделать имя клиента уникальным, но не рекомендуется использовать другой ключ для разных отношений.Внешние ключи обычно должны указывать на первичный ключ (который, я предполагаю, является идентификатором клиента?)

"и хитрый: все EntityServices в одном EngagementLetter должны иметь одного и того же клиента"

Что делатьты имеешь в виду?Есть ли связь между EntityServices и клиентом?есть один через сущности, вы имеете в виду идентификатор клиента, полученный из родительской строки связанных сущностей?Связано ли это каким-то образом с клиентом, с которым связано письмо-обязательство?

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

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

...