¿Cómo se configuran varias cuentas con bases de datos separadas para Django en un servidor?

¿Qué opciones hay para instalar Django de modo que varios usuarios (cada uno con una "Cuenta") puedan tener su propia base de datos?

La semántica es bastante intuitiva. Puede haber más de un usuario para una cuenta. Una cuenta tiene una base de datos única (y una base de datos corresponde a una cuenta). Imagen WordpressMU. :)

He considerado esto:

Solución externa: multiplex a múltiples servidores / demonios

Múltiples instalaciones de Django, con cada instalación / proyecto de Django correspondiente a una cuenta que establece su propio DATABASE_NAME, p.

Sistema de archivos:

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

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

Luego tener una instancia de Django ejecutándose para cada uno de bob y sue. No me gusta esta metodología, se siente brutal y huele mal. Pero estoy seguro de que funcionaría y, según las sugerencias, podría ser la forma más limpia e inteligente de hacerlo.

Las aplicaciones se pueden almacenar en otro lugar; lo único que debe ser exclusivo de la configuración de django es settings.py (e incluso allí, solo DATABASE_NAME, etc. debe ser diferente, el resto se puede importar).

(Por cierto, estoy usando lighttpd y FastCGI).

Solución interna: configuración de la base de datos de multiplexación Django

Por otro lado, he pensado en tener una sola instalación de Django, y

(a) Agregar un "prefijo_" a cada tabla de la base de datos, correspondiente a la cuenta del usuario conectado; o

(b) Cambiar la base de datos de acuerdo con la cuenta del Usuario que ha iniciado sesión.

Me interesaría especialmente ver la "forma de Django" para hacer esto (esperando que sea algo muy simple). Por ejemplo, middleware que toma un Usuario de solicitud y cambia django.conf.SETTINGS ['DATABASE_NAME'] a la base de datos para la cuenta de este usuario.

Esto levanta banderas rojas, a saber. ¿Es seguro para subprocesos? es decir, ¿cambiar django.conf.SETTINGS afecta a otros procesos? ¿Existe solo un peligro inherente al cambiar django.conf.SETTINGS? ¿Ya estaría configurada la conexión DB? ¿Reiniciar la conexión de la base de datos es parte de la API pública? - Voy a echar un vistazo a la fuente de Django cuando vuelva a ver este problema.

Soy consciente de que 2 (a) y (b) podrían requerir que la autenticación de usuario se almacene y acceda en un mecanismo diferente al del núcleo.

Por ahora, voy a ir con el mapeo externo en la capa del servidor web, es más simple y más limpio por ahora. Sin embargo, no me gusta la idea de que los demonios FastCGI se ejecuten para cada cuenta; parece que desperdicia innecesariamente la memoria, especialmente si habrá más de 2000 cuentas. Sin embargo, me gustaría mantener abierta esta discusión, ya que es un problema interesante y la solución no parece ideal para ciertos casos.

Comentarios debidamente apreciados. Salud

Respuestas a la pregunta(2)

Su respuesta a la pregunta