Creación de una aplicación web con varias instancias de base de datos o solo una instancia

Question

Actualmente estoy diseñando una aplicación web en la que los clientes se registrarán como empresas. Cada empresa tendrá su propio conjunto de usuarios. Mientras estoy diseñando esto, me pregunto qué enfoque funcionaría mejor. Veo sitios como fogbugz o basecamp que usan subdominios. En los casos con subdominios, ¿tiene una instancia de base de datos por subdominio? Me pregunto si se recomienda tener una instancia de base de datos por empresa o si debería tener algún tipo de tabla de empresa y administrar la compañía y las credenciales/datos de usuario, todo desde una base de datos.

¿Qué enfoque es el mejor? ¿Hay literatura sobre este tema (es decir, cualquier web o libro)?

gracias de antemano!

Answer 1

Tiene que sopesar sus opciones, ya que parte de esto será una cuestión de opinión y podría no ser factible para su implementación.

Dicho esto, me gustaría considerar el enfoque de base de datos única, por estas razones:

1. Mantenimiento: cuando se ejecuta una base de datos por cada 'cliente' registrada, se llega muy fácilmente una situación en la cualquier cambio o actualización que realice en el esquema de su aplicación debe aplicarse a cada instancia de base de datos única. Esto se pondrá ridículo, rápido.

2. Conveniencia: Es posible que desee estadísticas y estadísticas de uso, o de alguna manera para administrar todas estas bases de datos. Consultar una sola base de datos es comparativamente trivial para tratar de agregar la misma consulta para todas sus bases de datos. Esto no va a escalar.

3. Escalabilidad *: Como se mencionó en 2, necesitará un tipo especial de agregación para consultar cosas sobre sus clientes y su aplicación como un todo. Cuanto más grande sea tu aplicación, más compleja será tu consulta. El otro problema es que si un cliente usa la aplicación mucho más que otro, ¿qué se le animará a optimizar? ¿Tu aplicación, la base de datos del cliente más grande o la del cliente más pequeño? Sin olvidar que todo lo que hagas debe copiarse en todas las bases de datos.

4. Copias de seguridad: Puede hacer una copia de seguridad de una base de datos fácilmente, simplemente creando un volcado y escondiéndolo en alguna parte. Obtenga mil clientes y ahora tiene que ejecutar 1000 volcados de bases de datos, y asígneles un nombre lo suficientemente bueno como para poder identificarlos si una única base de datos se corrompe. ¿Cómo sabrá si esto sucede? Los errores de la base de datos se localizarán en esa específica, a diferencia de toda su aplicación.

5. UI: Un usuario se registra o es invitado a usar su aplicación y pertenece a un cliente en particular. ¿Vas a guardar esa cuenta de usuario en la base de datos del cliente? Si es así, vea la escalabilidad para el problema de trabajar con esa información cuando el usuario quiera cambiar su contraseña, o si desea enviarla por correo electrónico. Entonces, ¿le dices al usuario que te deje saber en qué base de datos se encuentran para que puedas encontrarlos?

6. Simplificación: Usted tiene una base de datos por cliente y quiere simplemente usar una sola. ¿Cómo los fusionas a todos sin romper significativamente las cosas? Habrá conflictos de clave primaria si usa ID automáticos incrementados; las URL marcadas se romperán si decide regenerar las claves; las claves externas en las tablas ya no señalarán los registros correctos. Su integridad de datos se reducirá.

Menciona los servicios de 'etiqueta blanca' que ofrecen sus productos a través de subdominios personalizados. No estoy al tanto de cómo funcionan estos, pero el subdominio es solo un registro CNAME o A básico en su archivo de zona DNS. El proceso de agregar estos se puede automatizar, y el diseño de la aplicación y un poco de la configuración del servidor pueden ocuparse de vincular estos subdominios con las cuentas y los datos correctos. Son sólo las direcciones URL, así que tal vez en el backend, la aplicación no diferencia entre:

http://client.example.com 
http://example.com/client 

general, sin embargo, usted puede decidir que todos estos problemas son cosas que puede y preferirían que tratar. Tenga en cuenta, sin embargo, que al hacerlo puede dispararse en el pie, y puede obtener mucho más de la elaboración de un esquema de base de datos único bien diseñado y un front-end bien abstraído.

* @ xQbert menciona el beneficio muy real de la escalabilidad con múltiples bases de datos. He enmendado esta respuesta para aclarar que estaba más preocupado con otros aspectos.