Как спроектировать БД под проект на Django?

Question

[Innoel]

Задача стоит такая: продумать БД для сайта-CRM ь(бэкэнд - Джанга, СУБД - Постгрес), на котором каждый пользователь имеет свою таблицу услуг, таблицу клиентов (а всем известно, что у человека может быть несколько номеров и т.п., что порождает доп. таблицы) и т.д, но так же у него может быть несколько, скажем, компаний или филиалов компаний

Опыта в создании БД мало, поэтому возник такой вопрос: как это организовать правильно?
У меня возникли такие варианты, но я не могу определиться:
1) Создавать новую БД под каждого юзера, записывать все компании одного юзера туда
2) Создавать новую БД под каждую компанию (чтобы избежать ситуации с огромными связующими таблицами даже для простых задач).
3) Сливать всё в одну БД, но в таком случае меня пугает то, что эти таблицы в итоге будут достигать огромных размеров, всё это будет работать медленно и т.п., да и структура так получается гораздо сложнее, огромное количество связующих таблиц и так далее, чего, вроде как, можно избежать вторым вариантом

Возможно, это стоит реализовать вообще в другом ключе, какие есть идеи? Может, есть рекомендации, что почитать, чтоб разобраться в вопросе?

А теперь суть вопроса относительно Django, в Джанге использумые БД прописываются в конфиге сразу, как тогда реализовать такой подход? Возможно ли в Джанге организовать создание новой БД под каждого пользователя при регистрации? Или стоит использовать вообще другой подход или даже другой бэкэнд в целом?

Comments

[sim3x]

Данная мешанина слов

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

никак не поясняет задачу

Напишите по пунктам, что нужно хранить и зачем

Answer 1

[szelga]

blog.antidasoftware.com/2017/07/saas-django-python...
традиционно предупреждаю о преждевременной оптимизации. если проект только начинается, можно, наверное, и без всего этого. потом уже, когда разрастётся, раскидать по базам.

Comments

[Innoel]

Спасибо, это как раз то, что мне нужно, в дополнении с ответом Руслан Гильфанов это решает все проблемы.

Answer 2

[vreitech]

> каждый пользователь имеет свою таблицу услуг
совершенно лишнее. для всех пользователей одна таблица услуг, в которой принадлежность конкретному пользователю через колонку id пользователя.
> может быть несколько номеров и т.п., что порождает доп. таблицы
то же самое.
> 3) Сливать всё в одну БД
самый нормальный вариант.

Comments

[Innoel]

а как тогда быть с вариантом, когда пользователь захочет добавить новый столбец к себе в таблицу с клиентами, к примеру?

[Руслан Гильфанов]

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

• Паттерн EAV (Entity-Attribute-Value), т.е. сущность, атрибут и значение как три таблицы в БД. На больших объёмах данных могут быть проблемы с производительностью, но работает;
  
• Поля типа JSON или JSONB (есть в PostgreSQL). Производительность по-лучше, но может потребоваться кастомизировать виджеты и поля форм Django, чтобы с этим было удобно работать в админке.
  

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

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

[vreitech]

Innoel, ну... задача, конечно, не из лёгких, но специалисты по СУБД сходятся во мнении, что в таком случае следует добавить этот столбец.

[Innoel]

Руслан Гильфанов, отлично, спасибо огромное!