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

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

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

Если вам нужно масштабировать, я думаю, что лучшее решениеcould be комбинация обоих подходов. Каждая модель имеет внешний ключ клиента, поэтому базы данных могут совместно использоваться, но затем вы разрабатываете механизм на более высоком уровне, чем Django, для направления клиентов в экземпляр сайта. Это позволяет вам размещать действительно больших арендаторов в их собственных базах данных с ресурсами, правильно настроенными только для них (например, надлежащим числом демонов mod_wsgi, числом соединений с базами данных, пулом memcache надлежащего размера и т. Д.), А арендаторы меньшего размера используют общие ресурсы.

https://github.com/bcarneiro/django-tenant-schemas У вас будет только один экземпляр проекта, и вам не придется вносить много изменений в ваш код.