¿Cuáles son las mejores prácticas en la creación de aplicaciones que admiten varios inquilinos, como Software as a Service?¿Cuáles son las mejores prácticas en la construcción de aplicaciones para varios inquilinos?
Los enlaces a libros blancos que amplían este tema son muy apreciados.
Puede encontrar algunos consejos valiosos en una serie de publicaciones de blog de Oren Eini.
Este es uno de los últimos puestos de la serie, con enlaces a los mensajes anteriores: http://ayende.com/Blog/archive/2008/08/16/Multi-Tenancy--Approaches-and-Applicability.aspx
Para la base de datos:
A. poner todo sobre la misma base de datos, poner una columna tenant_id en sus tablas
Pros: Fácil de hacer
Contras: muy propenso a errores: es fácil filtrar datos de un inquilino a otro.
B. Ponga todo en la misma base de datos, pero puso cada inquilino en su propio espacio de nombres
Pros (PostgreSQL les llama esquemas): proporciona una mejor protección que los datos se filtran opción A
Contras: No soportado por todas las bases de datos. AFAIK PostgreSQL y Oracle lo admiten.
C. Configuración de una base de datos por el inquilino
Pros: Absolutamente ninguna posibilidad de fugas de datos de un inquilino a otro
Contras: La creación de nuevos inquilinos es más complicado. Las conexiones de bases de datos son costosas.
Solo aprendí las ideas anteriores de Guy Naor. Aquí hay un enlace a su presentación: http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html
En #B, todos los esquemas de apoyo a las bases de datos, pero con una terminología diferente. En MySQL, el esquema y la base de datos son sinónimos. MSSQL también tiene soporte de esquemas ahora. Nuestra aplicación multiempresa en producción se ejecuta con ~ 4000 (a partir de ahora) bases de datos/esquemas en MySQL. –