Многопользовательский дизайн - обмен данными между схемами

Question

Давайте рассмотрим такой случай:

1. У пользователя может быть компания (или многие из них)
2. Пользователь может быть частью компании (или во многих из них)
3. Компания является единственным владельцем системы
4. Компания имеет список задач
5. Каждое задание назначено пользователю

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

вопрос в том, как подойти к этой проблеме

Возможные решения, о которых я подумал (но ни один из них не убедил меня):

1. Копирование данных всех пользователей, соответствующих компании, в схему компании (это потребовало бы достаточного количества синхронизации, поэтому я не нахожу это очень эффективным)
2. Переключение между схемами и «объединение» их программно - это требует много дополнительного кода для реализации, и это нарушаетЭто хорошая практика - поскольку user_id в задании выходит за пределы схемы tanant)

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

Answer 1

Звучит так, будто вам нужно несколько таблиц, например users, companies, tasks и связанных с ними таблиц.

Как правило, вы не хотите разделять сущности по нескольким таблицам.Вот несколько причин.

1. Поддерживать несколько таблиц проще, чем сотни или тысячи таблиц.
2. Базы данных более эффективны для больших таблиц,Распространение небольших таблиц приводит к большому количеству частично заполненных страниц данных для одного объекта.
3. Некоторые запросы - например, сколько задач в каждой компании - намного проще с одной таблицей.
4. При работе с несколькими таблицами такие запросы часто требуют использования динамического SQL, который просто беспорядок для простых задач.
5. Реструктуризация данных становится кошмаром, когда вам приходится применять реструктуризацию к миллиону таблиц, а ненесколько таблиц.
6. Добавление новых функций - это кошмар, когда его приходится повторять несколько раз.

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