Дизайн базы данных - лучший способ управлять этими отношениями

Question

Я работаю над проектом (основан на Django, хотя это не совсем соответствует моему вопросу), и я изо всех сил пытаюсь найти лучший способ представления моделей данных.

У меня есть четыре следующие модели:

Пользователь, Клиент, Встреча, Местоположение

Пользователь и Клиент имеют отношение многие-ко-многим через модель Встречи. Модель Meeting имеет непосредственное отношение к модели Location.

Встречи будут проходить по адресу:

1. Адрес, определенный в модели User (или UserProfile)
2. Адрес, определенный в модели клиента.
3. Некоторое другое местоположение, которое должно быть определено позднее.

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

• Я рассмотрел создание местоположения в качестве поля в модели собраний, а не в отдельной модели, хотя это также может привести к избыточным данным, если множество собраний создается в одном месте, так что это, вероятно, без стартера.

• Я мог бы автоматически создавать записи местоположения для каждого созданного пользователя и клиента и использовать общие отношения между соответствующими записями, однако я понимаю, что это может привести к неэффективной работе базы данных. Кроме того, не каждый клиент / пользователь сможет проводить собрания в своем местоположении.

Кто-нибудь может увидеть более аккуратную альтернативу?

Любой совет приветствуется.

Спасибо.

Answer 1

Я бы ожидал, что Встречи и Места будут иметь отношения многие-к-одному. Не может ли место использоваться для более чем одной встречи? (в разное время, конечно)

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

Answer 2

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

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

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

Так что я думаю, что вы должны изменить свое представление о модели собрания.

Вместо того чтобы пользователи имели отношения M: N с клиентами через модель Meeting, они должны иметь отношения M: N через, скажем, модель Attendance. (Модель регистрации или бронирования или MightAttend может быть более подходящей для вас.) И модель Meeting должна измениться, чтобы отразить уникальные атрибуты реальной встречи: время и место.