php - una - principios de diseño de bases de datos

Aplicación web PHP: pregunta de mejores prácticas de diseño de 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 base de datos de una aplicación web PHP que estamos creando. La aplicación está diseñada para empresas, y cada compañía que se registre tendrá múltiples usuarios que usen la aplicación.

Mi metodología de diseño es crear una nueva base de datos para cada empresa que se registre. De esta manera todo es caja de arena, modular y pequeño. Mi filosofía de compañeros de trabajo es poner a todos en una base de datos. Su argumento es que si tenemos más de 1000 empresas inscritas, terminamos con más de 1000 bases de datos con las que tratar. Sin mencionar el desorden en que se hace 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 cubo, las tablas pueden volverse muy grandes muy rápidamente.

¿Hay una mejor práctica para esto? Intenté buscar en la web, pero no he tenido mucho éxito. Enlaces, informes y presentaciones de bienvenida.

Gracias por adelantado,

The1Rob

Answer 1

Dirigimos un negocio de SaaS (software como servicio) con un gran número de clientes y hemos elegido mantener a todos los clientes en la misma base de datos. La gestión de miles de bases de datos separadas es una pesadilla operativa.

Tiene que ser muy diligente al crear su modelo de datos y las consultas de informes / objetos de negocio que acceden a ellos. Un enfoque que quizás desee considerar es llevar el ID de la empresa en cada tabla y asegurarse de que cada cláusula WHERE incluya el ID de la empresa para el usuario que ha iniciado sesión actualmente. Si utiliza una capa de acceso a datos, puede imponer esa condición allí.

A medida que crece, aún puede particionar verticalmente al colocar grupos de compañías en cada servidor físico, por ejemplo, las primeras 100 compañías en el Servidor A, las siguientes 100 compañías en el Servidor B.

Answer 2

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

Answer 3

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

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

A medida que los clientes van y vienen, y los blogs de algunos clientes tienen actividad de gran volumen, mientras que otros se vuelven obsoletos, el rebalanceo entre múltiples 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 también es más fácil.

Del mismo modo, hacer una copia de seguridad de la base de datos o restaurar una base de datos única que contenga terrabytes de datos, en comparación con las copias de seguridad de la base de datos individuales y las restauraciones de unos pocos megabytes cada una, es un factor importante. Considere: un cliente llama y dice que sus datos se debieron a 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 los datos de un cliente si todos sus clientes comparten una única base de datos?

Finalmente, decidieron que la división en una base de datos separada por cliente , aunque compleja de administrar, les ofreció una mayor flexibilidad y volvieron a diseñar su servicio de alojamiento para este modelo.

Entonces, si bien desde la perspectiva del modelado de datos parece ser lo correcto para mantener todo en una sola base de datos, algunas tareas de administración de la base de datos se vuelven más fáciles a medida que pasa un cierto punto de interrupción del volumen de datos.

Answer 4

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

Lo bueno es que los datos están segregados 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 5

La metodología de base de datos separada tiene un gran avance sobre la otra:
+ Podrías dividirlo en grupos más pequeños, esta arquitectura se amplía mucho mejor.
+ Podrías hacer servidores autónomos de una manera fácil.

Answer 6

No he manejado personalmente esta situación, pero creo que si desea hacer inteligencia empresarial, debe agregar los datos en una base de datos fuera de línea en la que pueda ejecutar el análisis que desee.

Además, mantenerlas 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 tener que recurrir a tecnologías de replicación desordenadas.

Answer 7

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

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

Answer 8

Tendría que estar de acuerdo con tu 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 habla (más de 1000 compañías, múltiples usuarios por compañía, más de 100 pedidos por día) están dentro de los límites esperados. Bases de datos separadas significa:

• Conexiones de base de datos múltiples en cada script (memoria y penalización de velocidad)
• el mantenimiento es más difícil (los sistemas de base de datos generalmente no proporcionan herramientas para actuar en bases de datos como grupo), por lo que los cambios de esquema, las copias de seguridad y tareas similares serán más difíciles
• Más difícil ejecutar consultas sobre datos de múltiples compañías

Si su sitio se vuelve enorme, es posible que tenga que distribuir sus datos entre varios servidores. Trata con eso cuando suceda. Comenzar de esa manera por razones de rendimiento suena como una optimización prematura.