Multi-arrendamiento - base de datos única vs base de datos múltiple

20

Tenemos varios clientes, cuyos sistemas comparten algunas funcionalidades, pero también tienen un alto grado de diversidad. El número de clientes está creciendo, ¡siempre es algo saludable! - y la diversidad entre sus negocios también está aumentando.

En la actualidad, hay un único sitio web ASP.Net (formularios web) (en oposición al proyecto web), que tiene subcarpetas para cada inquilino, con las páginas no estándar de ese inquilino. Hay un proyecto modelo separado, que se ocupa del acceso a la base de datos y la lógica empresarial.

Lo cual es preferible, y lo más importante, por qué, entre tener (a) 1 base de datos por cliente, con solo las características asociadas con ese cliente; o (b) una única base de datos compartida por todos los clientes, donde solo un subconjunto de tablas es utilizado por un solo cliente.

Las principales preocupaciones dentro del negocio han terminado:

mantenimiento de múltiples activos: copias de seguridad, control de versiones y similares
promoviendo la reutilización tanto como sea posible

¿Cómo se aseguraría de abordar estas preocupaciones, qué solución es preferible y por qué? (También he estado compilando respuestas a preguntas similares)

database-design projects-and-solutions multitenancy

— RichardW1001
fuente

¿Hay alguna posibilidad de que esto se mueva a un entorno de nube PaaS como Azure? Si es así, también querrás considerar las mejores prácticas para el medio ambiente. La última vez que miré, MS recomendó múltiples bases de datos para software de múltiples inquilinos en Azure.

— Harper Shelby

Gracias por preguntar. Me he estado preguntando cosas similares, pero no he podido poner el formato de pregunta tan elocuentemente como tú.

— MathAttack

Deberías leer la serie de blogs de múltiples inquilinos de Ayende. Él hace algunos puntos muy buenos sobre la base de datos multi vs única.

— Sebazzz

12

Aquí están los aspectos más destacados de la investigación de otras fuentes (originalmente de la revisión 2 de la pregunta ):

¿Debo usar una base de datos por aplicación o compartir una sola base de datos entre múltiples aplicaciones?
Apoyando multitenancy
Arquitectura de datos de múltiples inquilinos de MSDN
SO ¿Cómo crear una base de datos multiinquilino con estructuras de tabla compartidas?
CloudExpo SaaS: opciones de diseño de bases de datos de múltiples inquilinos
Blogs de MSDN Cambiar a un modelo de base de datos de múltiples inquilinos más fácil con las federaciones SQL Azure
Pregunta SQL Server Central ¿ Una base de datos o múltiples?
SQL Server Central Mezclando tablas de diferentes bases de datos / aplicaciones en una base de datos
Ayende @ Rahien blog Multi Tenancy - El modelo de datos físicos
Proyecto de código de arquitectura de base de datos de múltiples inquilinos
Joel en el diseño de bases de datos multiusuario de software
SO Aplicación múltiple que usa una base de datos?
SO Bases de datos únicas o múltiples
Code Rant - Multi-inquilino Parte 1, Estrategia y Parte 2, Componentes y contexto

— user40980
fuente

10

Si está utilizando SQL Server, use una base de datos pero use esquemas. Use dbo para cosas que son generales para todos los clientes y cree un esquema para cada cliente y haga que sea el esquema predeterminado para los usuarios de ese cliente. Ahora puede tener un objeto general (digamos un proceso getBudget) en el esquema dbo y uno personalizado para el cliente en su esquema con el mismo nombre.

— HLGEM
fuente

+1 Esto también le permitirá evitar tener que configurar MSDTC y asumir la sobrecarga asociada (confirmaciones de dos fases)

— Brian

Y es de esperar a evitar la trampa de tener columnas como CustomField1 través CustomField30 y / o tener tablas como el presupuesto, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName, etc.

— jfrankcarr

Existe una capa de acceso a datos existente que utiliza muchos procedimientos almacenados (190 tablas, 5 procedimientos generados por código por tabla, más algunos personalizados), mientras que el objetivo a mediano plazo es introducir Entity Framework, sería necesario replicar los almacenados procedimientos para cada esquema?

— RichardW1001

@ RichardW1001: depende. puede hacer SQL dinámico en el sp, para hacerlo genérico, pero eso, por supuesto, depende de que tengan una estructura al menos algo similar. Una posible alternativa para sql dinámico sería Sinónimos , desafortunadamente, según tengo entendido, son de todo el sistema y no están contenidos dentro de una transacción, por lo que no son adecuados para el uso concurrente con diferentes valores.

— jmoreno

Si usamos múltiples esquemas, usando EF Code First, ¿será posible migrar todos los esquemas a la última versión después de que el sistema se active?

— Yashvit

4

Dado que las bases de datos y la funcionalidad de los clientes son divergentes, significa que en un momento terminarán siendo sistemas diferentes, por lo que en este caso recomendaría sistemas separados, ya que los costos de mantener las personalizaciones para cada cliente superarán los beneficios de un solo sistema de bases de datos.

Los sistemas de bases de datos individuales son mejores para cuando los cambios entre diferentes clientes son meras configuraciones pero no características adicionales para cada cliente.

— Stephen Senkomago Musoke
fuente

¿Cuál sería su sugerencia sobre cómo administrar la funcionalidad común con un mínimo de dolor?

— RichardW1001

1

En su sistema de control de versiones, mantenga una cabeza para la aplicación principal y cree una rama principal para cada cliente, con sub-ramas para las nuevas características que necesitan mantener. Desarrolle características específicas del cliente en las sucursales, con opciones para actualizar la troncal, etc. Luego, puede activar entornos específicos del cliente con facilidad siempre que los necesite

— Stephen Senkomago Musoke

3

Te estás perdiendo algunas preocupaciones. Los problemas vendrán con el crecimiento. Si puede suponer que algún día crecerá más que un servidor de base de datos; una base de datos compleja definitivamente le causará dolor de cabeza. A menos que invierta en arquitectura por adelantado. Pero también es un paso costoso)

Por lo tanto, no olvide que es mucho más barato y muchas veces más fácil escalar pocas bases de datos diferentes que grandes)

— estímulo
fuente

¿Tiene algún dato que confirme la facilidad de escalado? Si es así, sería un caso muy convincente. ¿Podría dar más detalles sobre las otras preocupaciones que faltan? Estoy tratando de construir una discusión lo más completa posible en ambos lados.

— RichardW1001

1

Un área que no he visto abordada en las respuestas son los problemas para asegurar correctamente una aplicación de base de datos multiinquilino. Las aplicaciones de múltiples inquilinos deben diseñarse con mucho cuidado para evitar problemas de seguridad. La mayoría de las bases de datos y las aplicaciones proporcionan un aislamiento, pero no completo, por lo general, hay formas de inferir directa o indirectamente datos a través de los esquemas de base de datos. Y bastantes recursos compartidos (registros y otros archivos, tablas DBA, cursores ...) que pueden, al menos, conducir a ataques fáciles de denegación de servicio a otros inquilinos, y generalmente mucho más.

— Garceta
fuente