¿Bases de datos individuales o separadas para cuentas de clientes separadas?

Question

Estoy trabajando en una aplicación que recopila datos de tarjetas inteligentes. Quiero poder ejecutar la aplicación como un servicio web para múltiples cuentas de clientes. La pregunta es, ¿debería crear una base de datos separada para cada cuenta o debería diseñar una única base de datos que contenga todos los datos de las cuentas? En primer lugar, pensé que una base de datos única era la respuesta obvia, pero resulta que el AccountID tiene que ser utilizado en todas partes, en tablas, índices, restricciones, consultas, verificaciones, etc.

En esta aplicación, no hay un solo byte de datos que se va a compartir entre cuentas.

En primer lugar, vamos a ver cómo una base de datos independiente para una cuenta se vería:

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30)); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30)); 

A esto se añade un par de restricciones únicas,

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName); 
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName); 

Ahora, si pongo todo en una base de datos , significa que varias cuentas podrían manejar los mismos CardHolders y SmartCards, pero las cuentas no deberían ver los datos de los demás. Debido a esto, una SmartCard es única dentro de una cuenta, pero no dentro de toda la base de datos. Por lo tanto, cada restricción debe incluir un AccountID,

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30), 
    AccountID int); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30) 
    AccountID int); 

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName); 
ALTER TABLE SmartCard 
    ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName); 

En el actual DB, habrá un montón de más tablas, columnas y varios índices (para el listado de expirydate etc, etc) y la columna de AccountID tiene que ser incluido en todas partes .

Parece un poco abarrotado para mí, primero poner todas las cuentas en una única base de datos, y luego separarlas teniendo una columna AccountID en cada tabla y casi cada restricción e índice. También necesitaría encontrar o inventar algún tipo de seguridad a nivel de fila para evitar que los usuarios accedan a los datos de otras cuentas. Entonces, ¿tengo una excusa válida para crear una base de datos separada para cada cuenta, o los "diseñadores de bases de datos reales" siempre guardan todo en una sola base de datos?

Answer 1

Hay varias cosas que se deben tener en cuenta cuando se diseña una aplicación multi-tenant, incluyendo, como dice su pregunta, el diseño del esquema, pero también deben tenerse en cuenta aspectos tales como los costos de licencia, escalabilidad, etc. This article describes the three most common approaches for designing a multi-tenant application, incluidos los pros y los contras. Echale un vistazo.

Answer 2

En mi humilde opinión solo hay una forma. Múltiples bases de datos

1. Esto no sólo datos totalmente segura que nunca debe ser compartida
2. También permite a los esquemas de cambiar de forma independiente el uno del otro. Con eso me refiero a que con el tiempo, tal vez un inquilino sea mucho más grande que todos los otros estudiantes, y por lo tanto las necesidades especiales deben ser atendidas.
3. de copia de seguridad, restaurar las operaciones y las estrategias puede ser fácilmente formulado para bases de datos independientes
4. limitaciones y unicidad son más fáciles y más naturalmente expresado

Answer 3

Hemos bajado ambas rutas aquí. Tenemos una base de datos compartida para clientes más pequeños que no necesitan personalización y una base de datos separada (y base de código de aplicación para el caso) para clientes empresariales que sí lo hacen.

Ambos tienen sus ventajas y desventajas. En la base de datos compartida, todo lo que se necesita es una mala consulta en la que alguien olvidó utilizar el cliente y los datos están expuestos a otros clientes.En cinco años, he visto esto solo una vez, pero fue una gran pesadilla que nos costó un cliente. Si sigue esta ruta, asegúrese de tener un buen equipo de control de calidad que verifique exactamente eso antes de liberar el código para prod. Si su base de datos tiene esquemas, puede usar vistas en esquemas para evitar el acceso a datos de otros datos del cliente. Si el cliente solo tiene los derechos sobre sus puntos de vista, entonces no puede ver los datos de otra persona. Sin embargo, esto es más trabajo de configurar.

Pero las bases de datos separadas pueden convertirse en una pesadilla para realizar cambios de mantenimiento. Sin embargo, si vende sus actualizaciones, este es el camino a seguir, ya que no todos los clientes comprarán cada actualización. Solo asegúrese de tener un buen mecanismo de seguimiento para saber en qué versión está cada cliente y de que utiliza el control de origen para rastrear todos los cambios en la base de datos por versión, para que pueda actualizarlo fácilmente.

Si no tiene la intención de tener personalizaciones, puede encontrar que tener bases de datos separadas lleva en esa dirección de todos modos. Es mucho más fácil decirles que no cuando están en una base de datos compartida.

Además, hemos encontrado que hay personalizaciones que serían útiles para otros clientes pero debido a que se desarrollan en una aplicación y base de datos separadas, un equipo diferente las reconstruye para un cliente diferente y usted termina de 6 formas para hacer lo mismo Esto se convierte en un gran problema para las personas que trabajan con clientes como las personas que importan datos de clientes a las bases de datos. Personalmente prefiero el enfoque de una base de datos.

Otro punto relacionado con la necesidad de consolidar o separar las preocupaciones sobre el informe de los datos. Si los informes siempre serán hechos solo por el cliente, entonces puede separarlos, pero si necesita hacer informes (como su propio informe financiero interno) con datos consolidados, es mucho más fácil si tiene una base de datos consolidada. Traigo esto a colación porque las personas tienden a olvidarse de informar hasta que se establece el diseño y puede causar algunos problemas desagradables cuando lo haces.