Aplicación web PHP: prácticas recomendadas de diseño de la base de datos mysql

Question

Actualmente estoy en un debate con un compañero de trabajo sobre las mejores prácticas relacionadas con el diseño de la base de datos de una aplicación web PHP que estamos creando. La aplicación está diseñada para empresas, y cada empresa que se registre tendrá múltiples usuarios utilizando la aplicación.

Mi metodología de diseño es crear una nueva base de datos para cada empresa que se registre. De esta forma, todo es arena, modular y pequeño. La filosofía de mis compañeros de trabajo es poner a todos en una base de datos. Su argumento es que si tenemos más de 1000 compañías registradas, terminamos con más de 1000 bases de datos para tratar. Sin mencionar el lío que se convierte en Business Intelligence.

Por ejemplo, supongamos que la aplicación es un sistema de entrada de pedidos. Con bases de datos separadas, el tamaño de la tabla puede seguir siendo manejable incluso si cada empresa realiza más de 100 pedidos al día. En una aplicación de un solo segmento, las tablas pueden ser muy grandes muy rápidamente.

¿Existe una mejor práctica para esto? Intenté buscar en la web, pero no tuve mucho éxito. Enlaces, libros blancos y presentaciones de bienvenida.

Gracias de antemano,

The1Rob

Answer 1

Hablé con el arquitecto de la base de datos de wordpress.com, el servicio de alojamiento de WordPress. Dijo que comenzaron con una base de datos, que alberga a todos los clientes juntos. El contenido de un solo sitio de blog realmente no es mucho, después de todo. Es lógico pensar que una sola base de datos es más manejable.

Esto les funcionó bien hasta que obtuvieron cientos y miles de clientes, se dieron cuenta de que necesitaban escalar, ejecutar varios servidores físicos y alojar un subconjunto de sus clientes en cada servidor. Cuando agregan un servidor, sería fácil migrar clientes individuales al nuevo servidor, pero es más difícil separar los datos dentro de una única base de datos que pertenece al blog de un cliente individual.

Como los clientes van y vienen, y los blogs de algunos clientes tienen un gran volumen de actividad mientras que otros se vuelven obsoletos, el reequilibrio en varios servidores se convierte en un trabajo de mantenimiento aún más complejo. Monitorear el tamaño y la actividad por base de datos individual es más fácil también.

Asimismo, hacer una base de datos hacer copias de seguridad o restaurar de una única base de datos que contenga datos de terraby, versus copias de seguridad de bases de datos individuales y restauraciones de algunos megabytes cada una, es un factor importante. Considere: un cliente llama y dice que sus datos recibieron SNAFU debido a una entrada de datos incorrecta, y ¿podría restaurar los datos de la copia de seguridad de ayer? ¿Cómo restauraría uno datos del cliente si todos sus clientes comparten una única base de datos?

Eventualmente decidieron que la división en una base de datos separada por cliente, aunque compleja de administrar, les ofreció una mayor flexibilidad y rediseñaron su servicio de alojamiento a este modelo.

Así, mientras que desde una perspectiva de los datos de modeladoparece que lo que hay que hacer para mantener todo en una sola base de datos, algunos de administración de bases de datos tareas se vuelven más fácil a medida que pase un cierto punto de interrupción del volumen de datos.

Answer 2

no he ocupado personalmente de esta situación, pero yo creo que si usted quiere hacer inteligencia de negocio, usted debe agregar los datos en una base de datos fuera de línea que a continuación, puede ejecutar cualquier análisis que desee.

Además, mantenerlos en bases de datos separadas facilita la partición entre servidores (lo que probablemente tendrá que hacer si tiene más de 1000 clientes) sin recurrir a tecnologías de replicación desordenadas.

Answer 3

Hace un tiempo tuve una pregunta similar y llegué a la conclusión de que una única base de datos es drásticamente más manejable. En este momento, tenemos múltiples bases de datos (alrededor de 10) y ya se está convirtiendo en un dolor administrar especialmente cuando actualizamos el código. Tenemos que migrar todas las bases de datos individuales.

Lo bueno es que los datos se segregan limpiamente. Debido a la sensibilidad de nuestros datos, esto es algo bueno, pero hace que sea un poco más difícil mantenerse al día.

Answer 4

La metodología de base de datos independiente tiene un gran avance sobre la otra:
+ Se puede dividir en grupos más pequeños, esta arquitectura escala mucho mejor.
+ Podrías crear servidores independientes de una manera fácil.

Answer 5

Nunca crearía una nueva base de datos para cada compañía. Si desea un diseño modular, puede crearlo utilizando tablas y claves primarias y secundarias conectadas correctamente. Aquí es donde aprendí sobre database normalization y estoy seguro de que te ayudará aquí.

Este es el método que usaría. SQL Article

Answer 6

Eso depende de la probabilidad de que cambien sus esquemas. Si alguna vez tienen que cambiar, ¿podrán realizar esos cambios en forma segura en 1000 bases de datos separadas? Si se encuentra un problema de escalabilidad con su diseño, ¿cómo lo va a arreglar para 1000 bases de datos?

Answer 7

Operamos un negocio de SaaS (Software como servicio) con una gran cantidad de clientes y hemos elegido mantener a todos los clientes en la misma base de datos. Administrar miles de bases de datos separadas es una pesadilla operativa.

Tiene que ser muy diligente al crear su modelo de datos y los objetos comerciales/informes de consultas que acceden a ellos. Un enfoque que quizás desee considerar es llevar el ID de la compañía en cada tabla y asegurarse de que cada cláusula WHERE incluya la ID de la compañía para el usuario actualmente conectado. Si usa una capa de acceso a datos, puede aplicar esa condición allí.

A medida que crece, puede dividir verticalmente al colocar grupos de empresas en cada servidor físico, p. las primeras 100 compañías en el Servidor A, las siguientes 100 compañías en el Servidor B.

Answer 8

Tendría que estar de acuerdo con su compañero de trabajo. Las bases de datos relacionales están diseñadas para manejar grandes cantidades de datos, y los números de los que está hablando (más de 1000 empresas, usuarios múltiples por empresa, más de 100 pedidos/día) se encuentran dentro de los límites esperados. bases de datos separadas significa:

• múltiples conexiones de bases de datos en cada secuencia de comandos (memoria y la pérdida de velocidad)
• mantenimiento es más difícil (sistemas de base de datos no suelen proporcionar herramientas para actuar sobre bases de datos como un grupo) por lo cambios de esquema, copias de seguridad, y tareas similares serán más difíciles
• más difícil de ejecutar consultas sobre datos de múltiples empresas

Si su sitio se pone muy grande, que pueden llegar a necesitar para distribuir sus datos a través de múltiples servidores. Ocúpese de eso cuando suceda. Para comenzar de esa manera por razones de rendimiento suena como una optimización prematura.