sql server - transact - Bases de datos múltiples Vs Base de datos única con datos particionados lógicamente

tipos de particiones en base de datos (2)

Estoy reflexionando sobre un problema de diseño de base de datos. Cualquier ayuda sería muy apreciada.

Estamos diseñando una aplicación que tiene 20 tablas (que pueden crecer hasta aproximadamente 30 como máximo durante el desarrollo de nuevas funciones)

La pila de tecnología

MVC4, .NET 4.X, Entity Framework 5, SQL Server 2012, marco de membresía ASP.NET

No de usuarios

Tenemos la intención de atender a unos 1000 clientes que tendrían en promedio 20 usuarios.

La pregunta

Si diseñamos la base de datos y la aplicación de manera que las tablas se particionen lógicamente, es decir, todos los clientes usan las mismas tablas con una guía de partición para separar los datos.

Opte por múltiples bases de datos que podrían resultar difíciles durante el lanzamiento de nuevas funciones y la corrección de errores. ¿PERO podría potencialmente permitir la escala?

Advertencias: una de las tablas tiene una columna binaria que almacena archivos (máximo 5 MB por registro)

Además de esto, debemos tener en cuenta las tablas del marco de Membresía, que extenderemos a otra tabla personalizada y mapearemos lógicamente a los usuarios a una guía de partición.

Si está refiriendo su arquitectura arquitectónica como "multi arrendatario", Microsoft tiene un buen artículo que vale la pena leer here . Muestra una comparación entre "isolated" (multiple db) y "shared" (single db) . Generalmente, las ganancias compartidas cuando el número de inquilino (cliente) es grande, pero cuando el tamaño de cada inquilino es grande, se recomienda un enfoque aislado.

Sin embargo, esas consideraciones solo pueden ser calculadas por desarrolladores experimentados.

Aún así, si logró usar isolated (multiple db) arquitectura isolated (multiple db) , no obtendrá un beneficio directo en el rendimiento cuando aún se ejecutan en la misma instancia . Y si usa shared (single db) arquitectura shared (single db) , considere usar int lugar de guid , o sequential guid si aún necesita usarla.

Desearás haber usado bases de datos separadas:

Si alguna vez desea otorgar permisos a las bases de datos a clientes o superusuarios.
Si alguna vez desea restaurar solo la base de datos de un cliente sin afectar los datos de los demás.
Si hay preocupaciones regulatorias que gobiernan sus datos y violaciones de datos, y usted descubre tardíamente que estas regulaciones solo pueden cumplirse teniendo bases de datos separadas.
Si alguna vez desea mover fácilmente los datos de sus clientes a múltiples servidores de bases de datos o escalarlos, o mover clientes más grandes / más importantes a un hardware diferente. En otra parte del mundo.
Si alguna vez desea archivar y retirar fácilmente datos antiguos de clientes.
Si a sus clientes les preocupa que sus datos sean siledados, descubren que usted hizo lo contrario.
Si sus datos son citados y tiene que producir la base de datos completa en lugar de solo los datos para un cliente.
Cuando olvida mantener la vigilancia y solo se desliza una consulta que no incluye AND CustomerID = @CustomerID . Sugerencia: use una herramienta de permisos con script, o esquemas, o envuelva todas las tablas con vistas que incluyan WHERE CustomerID = SomeUserReturningFunction() , o alguna combinación de estos.
Cuando obtiene los permisos incorrectos en el nivel de la aplicación y los datos del cliente están expuestos al cliente incorrecto.
Cuando desee tener diferentes niveles de protección de copia de seguridad y recuperación para diferentes clientes.
Una vez que se dé cuenta de que la construcción de una infraestructura para crear, aprovisionar, configurar, desplegar y, de lo contrario, activar o desactivar nuevas bases de datos, vale la pena la inversión, ya que lo obliga a ser bueno en eso.
Cuando no permitió la posibilidad de que alguna clase de personas necesitara acceder a los datos de varios clientes, y necesita una capa de abstracción sobre el Customer porque WHERE CustomerID = @CustomerID no lo cortará ahora.
Cuando los piratas informáticos se dirigen a sus sitios o sistemas, y le facilitó la tarea de obtener todos los datos de una sola vez después de obtener las credenciales de administrador en una sola base de datos.
Cuando la copia de seguridad de su base de datos tarda 5 horas en ejecutarse y luego falla.
Cuando tiene que obtener la edición Enterprise de su DBMS para poder hacer copias de seguridad comprimidas, de modo que copiar el archivo de copia de seguridad a través de la red demore menos de 5 horas.
Cuando tenga que restaurar la base de datos completa todos los días en un servidor de prueba que demore 5 horas, y ejecute scripts de validación que demoren 2 horas en completarse.
Cuando solo algunos de sus clientes necesitan replicación y usted tiene que aplicarlo a todos sus clientes en lugar de solo a esos pocos.
Cuando quiere contratar a un cliente del gobierno y descubrir que requieren que use un servidor y una base de datos separados, pero su ecosistema se construyó alrededor de un solo servidor y una base de datos y es demasiado difícil o llevará demasiado tiempo cambiarlo.

Te alegrarás de haber usado bases de datos separadas:

Cuando un despliegue piloto para un cliente explota completamente y los otros 999 clientes no se ven afectados. Y puede restaurar desde copia de seguridad para solucionar el problema.
Cuando falla una de las copias de seguridad de su base de datos y puede corregirla en 25 minutos, en lugar de volver a iniciar todo el proceso de 10 horas.

Desearás haber usado una sola base de datos:

Cuando descubre un error que afecta a los 1000 clientes y es difícil implementar la solución en 1000 bases de datos.
Cuando se equivocan los permisos en el nivel de la base de datos y los datos del cliente se exponen al cliente incorrecto.
Cuando no permitió la posibilidad de que alguna clase de personas necesitara acceder a un subconjunto de todas las bases de datos (quizás dos clientes se fusionen).
Cuando no pensaste en lo difícil que sería fusionar dos bases de datos de datos diferentes.
Cuando combinó dos bases de datos de datos diferentes y se dio cuenta de que una era incorrecta, no planeaba recuperarse de este escenario.
Cuando intenta superar los 32,767 clientes / bases de datos en un solo servidor y descubre que este es el máximo en SQL Server 2012.
Cuando te das cuenta de que administrar más de 1,000 bases de datos es una pesadilla más grande de lo que nunca imaginaste.
Cuando se da cuenta de que no puede incorporar un nuevo cliente simplemente agregando algunos datos en una tabla, y tiene que ejecutar un montón de scripts complicados y de miedo para crear, rellenar y establecer permisos en una nueva base de datos.
Cuando tenga que ejecutar 1000 copias de seguridad de la base de datos todos los días, asegúrese de que todas tengan éxito, cópielas a través de la red, restáurelas todas en una base de datos de prueba y ejecute scripts de validación en cada una de ellas, informando cualquier falla de una manera que garantice Ser visto, y que son de fácil y rápida acción. Y luego, 150 de estos fallan en varios lugares y deben ser reparados uno a la vez.
Cuando descubra que tiene que configurar la replicación para 1000 bases de datos.

Solo porque enumeré más razones para uno no significa que sea mejor.

Algunos lectores pueden obtener valor de este artículo de MSDN: Arquitectura de datos de múltiples inquilinos