from - mysql workbench

Max Tables & Design Pattern (5)

Estoy trabajando en una aplicación ahora que tiene el potencial de crecer bastante. Toda la aplicación se ejecuta a través de un único dominio, y los clientes reciben subdominios, lo que significa que, por supuesto, todo se ejecuta a través de una base de código común.

Lo que estoy luchando es el diseño de la base de datos. No estoy seguro de si sería mejor tener una columna en cada tabla que especifique la identificación del cliente, o crear un nuevo conjunto de tablas (en la misma base de datos) o crear una base de datos completa por cliente.

Lo bueno de una "bandera" en la base de datos que especifica el ID del cliente es que todo está en una sola ubicación. Las caídas son obvias: las tablas pueden (serán) enormes, y el mantenimiento puede convertirse en una pesadilla completa. Si ocurre crecimiento, dividir esto en varios servidores va a ser un gran dolor.

Lo bueno de crear nuevas tablas es fácil de hacer, y también mantiene las tablas bastante pequeñas. Y dado que los datos de los clientes no necesitan interactuar, no hay ningún problema allí. Pero, de nuevo, el mantenimiento puede convertirse en un problema (aunque sí tengo una biblioteca de migraciones que hará actualizaciones sobre la marcha por cliente, por lo que no es gran cosa). El otro problema es que no tengo idea de cuántas tablas puede haber en una única base de datos. ¿Alguien sabe cuál es el límite y cuáles serían los problemas de rendimiento?

Lo bueno de crear una nueva base de datos por cliente es que, cuando necesite escalar, pueda hacerlo bastante bien. Hay varios sitios que hacen uso de este diseño (wordpress.com, etc.). Se ha demostrado que es efectivo, pero también tiene algunas caídas.

Entonces, básicamente, estoy buscando algunos consejos sobre qué dirección debería (podría) tomar.

¿Estás planeando desarrollar una aplicación en la nube?

Creo que no es necesario crear tablas o bases de datos por cliente. Te recomiendo que uses un sistema de administración de bases de datos relacionales más escalable. Personalmente no conozco las capacidades de MySQL, pero estoy bastante seguro de que debería soportar el modelo de base de datos distribuida para manejar la carga.

crear tablas o bases de datos por cliente puede llevarlo a una pesadilla de mantenimiento.

He trabajado con bases de datos de varias compañías y cada tabla contiene identificadores de clientes y para acceder a sus datos, desarrollamos vistas por cliente (para fines de informes)

Buena suerte,

El riesgo de compartir datos accidentalmente entre clientes es mucho menor con una base de datos separada. Si desea tener todos los datos en un solo lugar, por ejemplo para informar, configure una base de datos de informes a la que los clientes no puedan acceder.

Las bases de datos separadas le permiten implementar y probar una solución de errores para un solo cliente.

No hay límite en la cantidad de tablas en MySQL, puede hacer una gran cantidad de ellas. Sin embargo, llamaría a cualquier cosa por encima de cien tablas por base de datos una pesadilla de mantenimiento.

Puedes hacer lo que quieras.

Si tiene el ID_cliente en cada columna, entonces debe escribir toda la aplicación de esa manera. Eso no es exactamente cierto ya que debería haber suficiente para agregar esa columna solo a algunas tablas, el resto podría hacerse usando algunas combinaciones simples.
Si tiene una base de datos por usuario, no habrá ningún código adicional en la aplicación, por lo que podría ser más fácil.
Si realiza el primer acercamiento, no habrá problemas para moverse a muchas bases de datos, ya que puede tener la columna customer_id en todas esas tablas. Por supuesto, entonces habrá el mismo valor en esta columna en cada tabla, pero eso no es un problema.

Personalmente, tomaría el enfoque de cliente único de una base de datos. Más fácil de usar para los servidores de bases de datos para todos los clientes, más difícil mostrar los datos de un cliente que pertenece a algún otro cliente.

Varias bases de datos.

Diferentes clientes tendrán diferentes necesidades y le permitirán atenderlas mejor.

Además, si un cliente en particular está presionando la base de datos, no desea que afecte negativamente el rendimiento del sitio para todos sus otros clientes. Si todo está en una base de datos, no tiene mecanismo de control de daños.

Single Database Pros

Una base de datos para mantener. Una base de datos para gobernarlos a todos, y en la oscuridad, atarlos ...
Una cadena de conexión
Puede usar Clustering

Base de Datos Separada por Cliente Pros

Soporte para personalización por cliente
Seguridad: no hay posibilidad de que los clientes vean los datos de los demás

Conclusión

El enfoque de la base de datos por separado sería válido si planea apoyar la personalización del cliente. De lo contrario, no veo la seguridad como un gran problema: si alguien obtiene las credenciales de db, ¿de verdad crees que no verán qué otras bases de datos hay en ese servidor?