Какие есть варианты установки Django, чтобы у нескольких пользователей (у каждого из которых была «Учетная запись») могла быть своя собственная база данных?

Семантика довольно интуитивна. Может быть более одного пользователя для учетной записи. Учетная запись имеет уникальную базу данных (и база данных соответствует учетной записи). Картинка WordpressMU. :)

Я рассмотрел это:

Внешнее решение - мультиплекс на несколько серверов / демонов

Несколько установок Django, причем каждая установка / проект Django соответствует учетной записи, которая устанавливает свое собственное DATABASE_NAME, например,

Файловая система:

/bob
  /settings.py (contains DATABASE_NAME="bob")

/sue
  /settings.py (contains DATABASE_NAME="sue")

Затем наличие экземпляра Django для каждого Боба и Сью. Мне не нравится эта методология - она ​​кажется грубой и пахнет грязью. Но я уверен, что это сработает, и, основываясь на предложениях, это может быть самый чистый и разумный способ сделать это.

Приложения могут храниться в другом месте; единственная вещь, которая должна быть уникальной для конфигурации django, - это settings.py (и даже там, только DATABASE_NAME и т. д. должны отличаться, остальные могут быть импортированы).

(Между прочим, я использую lighttpd и FastCGI.)

Внутреннее решение - настройки базы данных мультиплексирования Django

С другой стороны, я думал об одной установке Django, и

(a) Добавление «prefix_» к каждой таблице базы данных, соответствующей учетной записи вошедшего в систему пользователя; или же

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

Мне было бы особенно интересно увидеть «способ Django», чтобы сделать это (надеясь, что это что-то очень простое). Например, промежуточное программное обеспечение, которое принимает пользователя запроса и изменяет django.conf.SETTINGS ['DATABASE_NAME'] на базу данных для учетной записи этого пользователя.

Это поднимает красные флаги, а именно. Это потокобезопасное? Т.е. влияет ли изменение django.conf.SETTINGS на другие процессы? Есть ли врожденная опасность при изменении django.conf.SETTINGS - будет ли уже установлено соединение с БД? Является ли перезапуск соединения с БД частью общедоступного API? - Я собираюсь взглянуть на источник Django, когда снова посмотрю на эту проблему.

Я осознаю, что 2 (a) и (b) могут потребовать, чтобы аутентификация пользователя сохранялась и осуществлялась в другом механизме, чем ядро.

Сейчас я собираюсь перейти к внешнему сопоставлению на слое веб-сервера - это пока самое простое и чистое. Однако мне не нравится идея запуска демонов FastCGI для каждой учетной записи - кажется, что она тратит впустую память, особенно если будет более 2000 учетных записей. Тем не менее, я хотел бы оставить это обсуждение открытым, поскольку это интересная проблема, и решение не кажется идеальным для определенных случаев.

Комментарии должным образом оценены. ура