Тернарные отношения в базе данных

Question

Предположим, я хочу смоделировать систему с сотрудниками и проектами. Каждый сотрудник может быть частью от 0 до n проектов, и проект может иметь от 0 до n сотрудников, работающих на нем. Для моделирования этого я создал 3 таблицы, employee, project и work со следующими отношениями

| employee | (0..n) < ----> (1..1) | work | (1..1) < ----> (0..n) | project |

Пока все хорошо, таблица work имеет только два атрибута (идентификатор от записи сотрудника и идентификатор проекта), и это работает нормально.

В каждом проекте также должен быть общедоступный «чат» и частный. Публика позволяет всем в компании видеть и отправлять сообщения в чат этого проекта. С другой стороны, в частном, только сотрудники, входящие в этот конкретный проект, могут видеть и отправлять сообщения.

Общедоступный чат легко моделируется, поскольку каждому разрешено просматривать сообщения. Я сомневаюсь в частном. Я хочу, чтобы принудительное условие частных сообщений в базу данных, так как личное сообщение связано с сотрудником, который является частью этого конкретного проекта. Способ, которым я нашел это, - добавить id в таблицу work и использовать этот идентификатор в качестве внешнего ключа в таблице private_message. Таким образом, соотношение между этими двумя таблицами будет:

| private_message | (1..1) < ----> (0..n) | work |

Это хороший способ смоделировать эту ситуацию? А если нет, то как я могу улучшить эту модель?

Спасибо.

Answer 1

Основываясь на том, что вы описали, сообщение имеет отношение «один к одному» с сотрудником, который его создал, и отношения «один к одному» с проектом, к которому он принадлежит. Учитывая это, я бы сохранить эти двух отношения как часть самого сообщения и буду моделировать private_message таблицы:

id, employee_id, project_id, message, whatever other field you need

Вы можете использовать существующую work таблицы, чтобы определить, какие сообщения любого лица, сотрудник должен быть в состоянии посмотреть на основе проектов, которым они назначены, используя следующий запрос:

SELECT private_message.* 
FROM private_message 
INNER JOIN 
    (SELECT project_id 
    FROM [work] 
    WHERE employee_id = <employee_id of user you need messages for>) assigned_projects 
     ON private_message.project_id = assigned_projects.project_id 

Answer 2

Я бы так не сделал. Я бы сохранил рабочий стол, как вы его изначально разработали, но добавьте поле, которое объединяет два идентификатора. Затем я ссылаюсь на это поле из таблицы private_message.

Добавление поля id для работы открывает вам дубликаты записей.