Deseará haber usado bases de datos separadas:
- Si alguna vez desea otorgar permisos a las propias 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 existen inquietudes normativas que rigen sus datos y las infracciones de datos, y descubre tardíamente que estas normativas solo se pueden cumplir si se tienen bases de datos separadas. (Actualización:un poco más de 4 años después de escribir esta respuesta, el RGPD entró en vigor)
- Si alguna vez desea mover fácilmente los datos de sus clientes a varios servidores de bases de datos o escalar horizontalmente, o mover clientes más grandes o más importantes a un hardware diferente. En una parte diferente del mundo.
- Si alguna vez desea archivar y retirar fácilmente los datos antiguos de los clientes.
- Si a sus clientes les preocupa que sus datos se almacenen en silos y descubren que usted no lo hizo.
- Si sus datos son citados y es difícil extraer solo los datos de un cliente, o si la citación es demasiado amplia y tiene que producir toda la base de datos en lugar de solo los datos de un cliente.
- Cuando olvida mantener la vigilancia y solo se le escapa una consulta que no incluía
AND CustomerID = @CustomerID. Sugerencia:use una herramienta de permisos con secuencias de comandos o esquemas, o ajuste todas las tablas con vistas que incluyanWHERE CustomerID = SomeUserReturningFunction(), o alguna combinación de estos. - Cuando obtiene permisos incorrectos en el nivel de la aplicación y los datos del cliente se exponen al cliente equivocado.
- Cuando desee tener diferentes niveles de protección de respaldo y recuperación para diferentes clientes.
- Una vez que te das cuenta de que vale la pena invertir en construir una infraestructura para crear, aprovisionar, configurar, implementar y, de lo contrario, activar o desactivar nuevas bases de datos porque te obliga a ser bueno en eso.
- Cuando no permitió la posibilidad de que alguna clase de personas necesitaran acceso a los datos de varios clientes, y necesita una capa de abstracción sobre
CustomerporqueWHERE CustomerID = @CustomerIDno lo cortaré ahora. - Cuando los piratas informáticos apuntan a sus sitios o sistemas, y les facilitó obtener todos los datos de todos sus clientes de una sola vez después de obtener las credenciales de administrador en solo uno 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 para que copiar el archivo de copia de seguridad a través de la red tome menos de 5 horas más .
- Cuando tiene que restaurar la base de datos completa todos los días en un servidor de prueba, lo que demora 5 horas y ejecutar secuencias de comandos de validación que demoran 2 horas en completarse.
- Cuando solo unos pocos de sus clientes necesitan replicación y tiene que aplicarla a todos sus clientes en lugar de solo a esos pocos.
- Cuando quiere contratar a un cliente del gobierno y descubre que requiere que use un servidor y una base de datos independientes, pero su ecosistema se creó en torno a un solo servidor y 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 lanzamiento piloto para un cliente explota por completo y los otros 999 clientes no se ven afectados en absoluto. Y puede restaurar desde la copia de seguridad para solucionar el problema.
- Cuando una de las copias de seguridad de su base de datos falla y puede arreglar solo esa en 25 minutos en lugar de comenzar todo el proceso de 10 horas nuevamente.
Deseará haber utilizado una sola base de datos:
- Cuando descubre un error que afecta a los 1000 clientes y es difícil implementar la corrección en 1000 bases de datos.
- Cuando obtiene permisos incorrectos en el nivel de la base de datos y los datos del cliente se exponen al cliente equivocado.
- Cuando no permitió la posibilidad de que alguna clase de personas necesitaran acceso a un subconjunto de todas las bases de datos (quizás dos clientes se fusionen).
- Cuando no pensaste lo difícil que sería fusionar dos bases de datos de datos diferentes.
- Cuando ha fusionado dos bases de datos de datos diferentes y se da cuenta de que una era la incorrecta y no planeó 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 1000 bases de datos es una pesadilla más grande de lo que jamás imaginaste.
- Cuando te das cuenta de que no puedes incorporar a un nuevo cliente simplemente agregando algunos datos en una tabla, y tienes que ejecutar un montón de secuencias de comandos aterradoras y complicadas para crear, completar 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 funcionen correctamente, cópielas a través de la red, restáurelas todas en una base de datos de prueba y ejecute secuencias de comandos de validación en cada una, informando cualquier falla de una manera que se garantizará que se verán, y que son fácil y rápidamente procesables. Y luego 150 de estos fallan en varios lugares y deben repararse uno a la vez.
- Cuando descubre que tiene que configurar la replicación para 1000 bases de datos.
El hecho de que enumeré más razones para una no significa que sea mejor.
Algunos lectores pueden obtener valor de MSDN:Multi -Arquitectura de datos de inquilinos . O tal vez Patrones de diseño de aplicaciones de tenencia SaaS . O incluso Desarrollo de múltiples inquilinos Aplicaciones para la Nube, 3ra Edición
