performance - Una base de datos o muchos?

database-design multi-tenant (11)

Estoy desarrollando un sitio web que administrará datos para múltiples entidades. No se comparten datos entre entidades, pero pueden ser propiedad del mismo cliente. Un cliente puede querer administrar todas sus entidades desde un solo "tablero de instrumentos". Entonces, ¿debería tener una base de datos para todo o mantener los datos separados en bases de datos individuales? ¿Hay una mejor práctica? ¿Cuáles son los aspectos positivos / negativos para tener un:

base de datos para todo el sitio (la entidad tiene un "ID de cliente", los datos tienen "ID de entidad")
base de datos para cada cliente (los datos tienen "entityID")
base de datos para cada entidad (la relación de la base de datos con el cliente está fuera de la base de datos)

Múltiples bases de datos parecen tener un mejor rendimiento (menos filas y uniones) pero eventualmente pueden convertirse en una pesadilla de mantenimiento.

¿Qué hay de la copia de seguridad y restauración? ¿Podría experimentar un cliente que desea restaurar una copia de seguridad de una de sus entidades?

Creo que es difícil responder sin más información.

Me apoyo en el lado de una base de datos. Los objetos comerciales debidamente codificados deberían evitar que se olvide del ID del cliente en sus consultas.

El tipo de base de datos que está utilizando y su escalabilidad pueden ayudarlo a tomar una decisión.

Para los cambios de esquema en el futuro, parece que una base de datos sería más fácil desde una perspectiva de mantenimiento: usted tiene un lugar para hacerlos.

Este es un escenario bastante normal en aplicaciones SAAS de múltiples usuarios. Ambos enfoques tienen sus pros y sus contras. Busque las mejores prácticas para SAAS multi-tenant (software como servicio) y encontrará toneladas de cosas para considerar.

Si el cliente alguna vez necesitara restaurar solo una entidad desde una copia de seguridad y dejar las otras en su estado actual, entonces el mantenimiento será mucho más fácil si cada entidad está en una base de datos separada. si se pueden respaldar y restaurar juntos, entonces puede ser más fácil mantener las entidades como una única base de datos.

Un buen argumento para mantenerlos en bases de datos separadas es que es más fácil de escalar (simplemente puede tener múltiples instalaciones del servidor, con las bases de datos del cliente distribuidas en los servidores).

Otro argumento es que una vez que haya iniciado sesión, no necesita agregar un cheque adicional (para identificación del cliente) en cada una de sus consultas.

Entonces, un DB maestro respaldado por múltiples DB para cada cliente puede ser un mejor enfoque,

Creo que tienes que elegir el escenario más realista y no necesariamente lo que un cliente "puede" querer hacer en el futuro. Si va a comercializar esa característica (es decir, ver todas sus entidades en un tablero), entonces tiene que encontrar una solución (tal vez tener el panel de control extraído de múltiples bases de datos) o utilizar una única base de datos para toda la aplicación.

En mi humilde opinión, tener los datos para múltiples clientes en la misma base de datos me parece una mala idea. Deberá recordar siempre filtrar sus consultas por ID de cliente.

Personalmente, prefiero bases de datos separadas, específicamente una base de datos para cada entidad. Me gusta este enfoque por las siguientes razones:

Más pequeño = más rápido con respecto a las consultas.
Las consultas son más simples.
Sin riesgo de mostrar accidentalmente los datos de un cliente a otro.
Una base de datos podría presentar un cuello de botella de rendimiento a medida que aumenta (el número de entidades aumenta). Obtiene un tipo de construcción en escalabilidad horizontal con 1 por entidad.
Fácil limpieza de datos a medida que se eliminan clientes o entidades.

Seguro que tomará más tiempo actualizar el esquema, pero en mi experiencia las modificaciones son poco comunes una vez que se implementan y las adiciones son triviales.

Mira este artículo en el sitio de Microsoft. Creo que hace un buen trabajo al establecer los diferentes costos y beneficios asociados con los diseños Multi-Tenant. También mire el artículo Multi tenancy sobre wikipedeia. Existen muchos intercambios y su mejor opción depende en gran medida del tipo de producto que esté desarrollando.

También depende de su RDBMS, por ejemplo

Con las bases de datos SQL Server son pío

Con Oracle es fácil dividir las tablas por cliente "customerID", por lo que una sola base de datos grande puede ejecutarse tan rápido como una pequeña base de datos para cada cliente.

Sin embargo, cada vez que elija, intente ocultarlo como un nivel bajo en su código de acceso a datos

¿Planeas tener tu código implementado en múltiples entornos?

Si es así, intente mantenerlo dentro de una base de datos y tenga todas las referencias de tabla con el prefijo de un espacio de nombres de un archivo de configuración.

La opción de base de datos única facilitaría el mantenimiento.