V / s individuales Bases de datos múltiples

He creado esta aplicación web (php y mysql) que almacena información para varias organizaciones (aproximadamente 20 clientes actualmente).

El escenario actual almacena información relacionada con el cliente en bases de datos individuales, por lo que hay 20 bases de datos de clientes y 1 base de datos maestra.

Una de las principales ventajas aquí es que a medida que cada cliente db está aislado, se secuencia la numeración de los artefactos del cliente (informes, auditorías), etc. dando a nuestros clientes una sensación de seguridad.

Cada base de datos tiene aproximadamente 15 tablas, y la mayoría de las filas en una tabla son alrededor de 2000. Se espera que esto supere los 5000 registros, como máximo.

Administrar un solo cambio de nivel de base de datos significa cambiar 20 bases de datos, pero en el raro caso de que necesite hacer dicho cambio, utilizo un script que hace esto en una sola llamada de función.

Estamos en un acuerdo de alojamiento compartido, y nuestro ISP nos proporciona un número limitado. de bases de datos; y eso es lo que me llevó a pensar en términos de centralizar la base de datos; para que TODOS los datos del cliente puedan almacenarse en la base de datos maestra.

Por supuesto, algunos problemas importantes que surgen son:

a. Mantener la secuencia de artefactos (esto podría solucionarse creando una clave de referencia adicional) b. Velocidad y rendimiento (en cuyo caso puedo crear índices para acelerar las cosas) c. Seguridad: esto se administrará como cada consulta que obtenga información del cliente. también rastreará su client_id

En el futuro, podríamos necesitar comparar los conjuntos de datos de una organización con otra, pero creo que eso también se puede lograr en una base de datos centralizada. Estoy algo inclinado (por razones de rendimiento y mantenimiento) a pasar a una base de datos centralizada.

¿Crees que pasar a una base de datos centralizada tiene más sentido que permanecer como estamos (en bases de datos individuales)?

Gracias por su consejo.

Hay riesgos heredados y recompensas para ambos sistemas. Trabajé para una empresa financiera que apoyaba a aproximadamente 40 clientes (bancos nacionales) en 1 base de datos. Luego compramos otra compañía que vendía software similar y que se había ido con 1 base de datos por cliente. Finalmente, la empresa se declaró en quiebra y tuvimos que exportar todos los datos de los usuarios. Esto es lo que la gente con la que trabajé y que encontré:

Pro de Single DB:

1. Las actualizaciones de software y las correcciones de errores son más fáciles.
2. Fácil de administrar e informar sobre todos los datos del cliente.
3. Actualizar datos se vuelve más fácil.
4. Funcionalidad modular fácil de crear que quiere 1 cliente, desactívela para los otros clientes y luego actívela cuando lo desee en el futuro.

Contras de DB simple:

1. Integridad de los datos: tuvimos 2 o 3 casos en los que los usuarios de 1 banco vieron los datos de otro banco. Esto fue una pesadilla. ¡Especialmente porque los usuarios del sitio no eran solo los empleados del banco, sino clientes reales del banco! Este es, con mucho, el mayor problema con 1 base de datos
2. Exportar datos del cliente: cuando teníamos que hacer esto, generalmente no era un gran problema. Terminas con 1 tabla que contiene todos los clientes y te desconectas de esa tabla para obtener los datos específicos de tu cliente.

Profesionales de múltiples bases de datos:

1. No hay preocupación por contaminación de datos de clientes cruzados o violaciones
2. Exportar los datos de un cliente es muy fácil.

Contras de múltiples bases de datos:

1. Actualizaciones y correcciones de errores: esta fue la verdadera pesadilla. Cuando tiene 20 clientes en 20 bases de datos diferentes, rápidamente se encuentra con el caso en el que 1 cliente quiere corregir un error y otro piensa que el error es una característica o no quiere arriesgar la actualización. Además, tendrá instancias en las que 1 cliente quiere una mejora que cambie el juego, pero los otros clientes no. Cuando esto sucede, sus bases de datos comenzarán a divergir. De repente, tendrá que actualizar los clientes 1-15 con 1 script 16-19 con otro y 20 con un tercero. Vimos que esto se convirtió en un problema tan grande que una corrección de errores tomaría entre 15 y 20 veces más tiempo para la compañía que compramos que para nosotros porque tuvieron que ejecutar todas las pruebas para cada cliente y tratar con el código especial de cada cliente. Efectivamente, necesitaban una nueva persona de soporte para cada nuevo cliente,
2. Administración de bases de datos: cuando llega a un gran número de clientes, administrar todas las bases de datos se convierte en una verdadera molestia. Sin duda necesitará más tiempo de DBA para administrarlos.

¡Al final, mi recomendación de haber visto y hecho ambas cosas es tener "disciplina"! Creo que la opción multi-db es un poco mejor porque te protege, pero nunca puedes dejar que tus clientes hagan una elección que haga que agregues funcionalidades solo a ellos o te encaminarás al fracaso.

Tendría una base de datos separada para clientes separados. Un cliente puede exigir esto por razones de seguridad, es decir, solo su sitio tiene acceso a sus datos. También significa que si un cliente desea mover sus datos, será mucho más fácil de administrar.

También significa que si hay un problema con la base de datos de un cliente, no afecta a todos los demás.

Si desea comparar datos entre clientes, debe hacerlo por separado.

Si se está quedando sin bases de datos que puede tener, entonces tal vez debería considerar cambiar su proveedor de host.

La única razón por la que no tendría una base de datos individual para cada cliente es si va a tener 100 o 1000 de clientes / bases de datos. Esto podría ser realmente difícil de manejar, incluyendo hacer cambios en la base de datos o hacer algo en todas las bases de datos. Las acciones que se producen en un gran número de bases de datos múltiples también pueden ser lentas, ya que necesita abrir (y, por lo tanto, cerrar) tantas tablas.

Pero aparte de este caso, creo que varias bases de datos son mejores.

Una ventaja, que puede no ser importante, pero puede ser útil, es que cada cliente obtiene sus propios ID secuenciales (en lugar de posiblemente omitir un montón porque otros clientes agregaron registros).

Además, varias bases de datos permiten que las subtablas (como el tipo de teléfono) sean fácilmente personalizables por cliente sin la necesidad de una identificación de registro principal en estas tablas también.

Primero la secuencia de artefactos. Supongo que está utilizando claves primarias enteras para proporcionar esto. Realmente debería tener una columna separada de "número de artefacto". Los PK deben ser PK y nada más. La gente habla de "claves naturales" y cosas por el estilo, y me estremezco. Cada vez que confías en que el PK es más que un identificador, vuelve a morderte. Si desea conocer la secuencia de algo, guarde una fecha o un número de secuencia.

Creo que en su caso, la gestión de la configuración lo conduciría a una única base de datos. Mire lo que le cuesta a tiempo mantener y actualizar las bases de datos. ¿Qué costos están asociados con cada versión del software? También piense en el costo cuando obtenga un nuevo cliente y tenga que crear una base de datos y configurar la aplicación para ello. Cualquier cosa puede ser automatizada, la pregunta es, ¿valdrá la pena cuando tenga 100 bases de datos?

En el futuro, es más fácil escalar (particionar, hardware, fragmentación, etc.) una sola base de datos que hacer lo mismo para 100 bases de datos.

Creo que los otros carteles han hecho algunos puntos excelentes, así que no los repasaré.

Para agregar a las ventajas y desventajas enumeradas hasta ahora:

Profesionales de múltiples bases de datos:

1. Se evitan los problemas de bloqueo; Tenemos bases de datos donde los clientes pueden activar cambios DDL en algunas de las tablas. Para las tablas más grandes (> 2m de registros) esto bloquea la tabla durante un tiempo considerable. Las únicas personas en desventaja son sus propios usuarios, por lo que esto es aceptable.

2. Flexibilidad: algunos clientes tienen deseos específicos con respecto a los datos que desean almacenar; la base de datos múltiple nos permitió la flexibilidad de alterar su base de datos específicamente, sin tener que saturar el modelo de datos para los otros clientes.

Contras:

1. Estafa importante: unirse en otras mesas es mucho más engorroso. Tenemos una base de datos principal que contiene la mayoría de los metadatos. Los usuarios de la base de datos específica del cliente no tienen acceso a esta base de datos, por lo que todas las uniones entre tablas en esa base de datos y la específica del cliente se manejan en la aplicación en lugar de en la base de datos. Puede resolver esto dando a los usuarios específicos del cliente acceso a la base de datos principal, pero luego la aplicación podría / podría filtrar información nuevamente.

¡Buena suerte al elegir!

Sé que ya ha elegido una respuesta, pero parece que hay otra solución que no se sugirió:

Mueva todo a una base de datos, pero cree tablas para cada cliente, usando un prefijo, como este:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Es una especie de lo mejor de ambos mundos.

• Es muy fácil migrar desde su configuración actual a la nueva configuración.
• Puede crear 1 usuario por cliente y restringir sus privilegios a las tablas de su empresa y nada más.
• Puede crear un superusuario y agregar datos fácilmente si lo necesita.
• Use solo una base de datos