Tuvimos exactamente este problema hace unos meses en una producto que a menudo utilizan las organizaciones que, a su vez, atienden a múltiples clientes. Vinieron a pedirnos que modifiquemos nuestro sistema SaaS para que puedan crear sitios web completos y discretos para cada uno de sus clientes (creamos una herramienta de construcción de sitios web en línea y específica del dominio).
Un breve resumen: puede parecer obvio poner a todos en una única base de datos, pero, a medida que profundiza, descubrirá que no siempre es una realidad. Hay algunos desafíos que debe tener en cuenta a medida que avanza. Un par de puntos:
En primer lugar, no basta con agregar "Company_id" a algunas tablas. De hecho, a pesar de los comentarios de Sai sobre que es ridículo tener una base de datos/aplicación para cada compañía, hay casos en los que esto tiene sentido debido a la complejidad subyacente de hospedar sistemas SaaS para clientes múltiples y discretos. Si simplemente es que ofrece algunas empresas diferentes (por ejemplo, crear facturas para ellos), entonces el comentario de Sai es bastante cierto. Sin embargo, si proporciona una aplicación de software a varias organizaciones, la complejidad es bastante mayor y las bases de datos discretas pueden estar en orden.
En segundo lugar, prepárese para un esfuerzo de informes y consultas del usuario significativamente más complejo en una base de datos multicliente. Por ejemplo, cuando desarrollamos nuestras capacidades de consulta de usuarios, teníamos que estar absolutamente seguros de que no habría un "desbordamiento" entre las organizaciones, ya que había datos protegidos por HIPAA implicados. Esto significaba que las capacidades de consulta e informes requerían un nivel de ingeniería muy superior al que había existido anteriormente.En nuestro caso, nuestras capacidades de consulta fueron muy flexibles y, esencialmente, permitieron a los usuarios construir consultas sobre la marcha (sujetas a algunas restricciones muy duras, obviamente, ¡no estábamos aceptando SQL!). Por lo tanto, teníamos que asegurarnos de que cada consulta se modificara automáticamente para usar la restricción "ID de la empresa", según corresponda, sin importar el origen de los datos o los permisos del miembro del personal que envía la consulta. La arruga? Nuestra cuenta de análisis 'superusuario' tenía que poder ejecutar las consultas sin dicha restricción ...
En tercer lugar, probablemente todavía no anticipe cuántas cosas deben separarse. Por ejemplo, construí un objeto "Configuraciones" bastante sofisticado en el sitio que extraía configuraciones de la base de datos al inicio y las mantenía en el objeto "Aplicación" (esta es una aplicación .NET). Todo esto debe ser flotado para manejar múltiples organizaciones.
Para otro ejemplo, los campos que solían ser únicos para nosotros (por ejemplo, los inicios de sesión) ahora tenían que hacerse como parte de un Clave ID de inicio de sesión de Company_ID. Si está construyendo desde cero, esta no es una gran idea, pero estábamos modernizando, así era.
De todos modos, a medida que avanzaba en la construcción, me sorprendí al descubrir cuánto trabajo se requería para hacerlo bien.
En cuarto lugar, siempre construyo software usando un enfoque de "meta-programación". Es decir, rara vez construyo una página de propósito único, sino que a menudo construyo un marco altamente personalizable para facilitar la personalización del usuario final y la reutilización interna del código. Si bien anticipé que esto ayudaría con la transición a bases de datos de múltiples organizaciones, ¡a menudo no lo hacía! Debido a que dicha codificación a menudo es bastante compleja para empezar, flotar la Organización era a menudo más difícil que si simplemente tuviera una página web vainilla.
Por último, si no hay necesidad urgente de compartir datos (por ejemplo, análisis de patrones de uso generales), entonces puede que desee apegarse a bases de datos discretas simplemente para facilitar el escalado. Mientras agrega nuevas bases de datos de múltiples organizaciones (un segundo sistema discreto), nuestra escala a menudo implicaba clientes existentes que de repente experimentaron un aumento en el crecimiento. Pelarlos de una base de datos existente y en un nuevo servidor es un poco más difícil que simplemente mudarse a un nuevo servidor con una base de datos existente.
Con todas estas advertencias, puede pensar que le aconsejaría que no cree un sistema capaz de manejar múltiples organizaciones en una sola base de datos. Sin embargo, este no es el caso: ¡hay algunos triunfos reales que adoptan un enfoque de múltiples organizaciones! El análisis de uso, los informes entre organizaciones, la implementación de aplicaciones, etc. se han mejorado significativamente. Solo quiero brindarle el beneficio de nuestra experiencia con la esperanza de que lo ayude a anticipar algunas de las dificultades que puede anticipar.
No, no estoy buscando exponer el DB directamente. Mi preocupación era solo el rendimiento a largo plazo. Y sí, ahora parece tonto replicar DBs: cualquier cambio en el esquema, las copias de seguridad serían horrendas. –
Esto depende completamente de la cantidad de datos por compañía de la que estamos hablando.En un caso general, company_id puede funcionar bien, aunque si usted es, por ejemplo, Salesforce, no hay una arquitectura maestro/esclavo que pueda contenerlo, y necesita una escala horizontal de todos modos (aunque no a una tasa de 1 DB por empresa) Si eres Facebook, creas una nueva instancia de MySQL por universidad, y eso te permite escalar desde el primer momento, aunque introduce dolores de cabeza de consultas cross-db. – SquareCog
En realidad, no estoy seguro acerca de Salesforce. Dado lo lento que es, podría estar ejecutándose en una sola instancia gigante de Oracle RAC e intentando grabar los datos de todos al generar sus informes :-). – SquareCog