Cómo diseñar una base de datos SaaS

Question

Tengo una aplicación web que he creado para una empresa de transporte por carretera que me gustaría ofrecer como SaaS. ¿Cuál es la mejor manera de diseñar la base de datos?

¿Debo crear una nueva base de datos para cada empresa? ¿O debería usar una base de datos con tablas que tengan un prefijo del nombre de la compañía? ¿O debería usar una base de datos con una de cada tabla y simplemente agregar un campo de identificación de la empresa a las tablas? ¿O hay alguna otra forma de hacerlo?

Answer 1

frente a una situación similar hace unos 10 años, optamos por una base de datos por cliente. tenemos cientos (no miles) de clientes. mirando hacia atrás fue una de las mejores decisiones que tomamos. las copias de seguridad son fáciles. copiar un único cliente a nuestra oficina para su análisis es fácil (solo tome la última copia de seguridad). escalar es fácil (mover un único cliente grande a un servidor diferente puede liberar recursos en un servidor sql estresado). joel & jeff tuvo una discusión sobre esto en un stack overflow podcast (no es reciente) y joel hizo lo mismo que yo ... cada cliente tiene su propia base de datos. Los puristas de bases de datos a menudo argumentan para agrupar a todos en un DB, pero nunca haría eso.

-don

Answer 2

Depende, aquí, yo trabajo en una empresa que tiene muchos "Las unidades de negocio internas" tratadas igual que otras compañías. Por lo tanto, algunos informes deben incluir todas las empresas, las cuentas de los clientes también deben compartirse entre las empresas. Aquí tenemos un campo CompanyId en las tablas que lo requiere. La solución Prefix es seguramente una que debe evitarse.

Answer 3

What are the advantages of using a single database for EACH client?

Should I use a single or multiple database setup for a multi-client application?

https://stackoverflow.fogbugz.com/default.asp?W24218 (podcast de transcripción, la discusión alrededor de 50 minutos en)

Answer 4

Tenemos algunas bases de datos aquí con clientes compartidos y algunos donde cada cliente tiene su propio servidor y base de datos propia. Aquellos en los que el cliente se encuentra en su propio servidor son los más fáciles de administrar y los menos propensos a causar problemas cuando un desarrollador olvida agregar el clientid y envía los datos del cliente al cliente b por accidente (un ejemplo NO elegido al azar).

Mantener cada uno en su servidor o instancia de servidor nos permite mantener la estructura de la base de datos con los mismos nombres y facilita la propagación de cambios a todos los servidores porque no tenemos que cambiar el nombre de la base de datos.

Si utiliza instancias separadas para cada cliente, asegúrese de diseñar e implementar un buen sistema para propagar todos los cambios a todos los clientes. Si estas bases de datos no se sincronizan, pueden volverse horribles de mantener. Descubrirá que si deja que se desincronicen, cada cliente pedirá cambios y tendrá 27 maneras de hacer lo mismo. Debe generalizar cuando están en la misma base de datos, cuando están separados, debe usar la autodisciplina para garantizar que la nueva funcionalidad sea la misma para cada cliente.

Answer 5

¿Debo crear una nueva base de datos para cada empresa?

Sí - Don Dickinson estaba en el dinero. Sin embargo, vea un refinamiento a continuación.

¿O debería utilizar una base de datos con tablas que tengan un prefijo del nombre de la empresa ?

Lord no! ¡Cambiar las consultas de la base de datos por diferentes para el cliente te volvería loco! Además, es casi seguro que ejecute SQL dinámico (donde el nombre de la tabla se cambia en código antes de ejecutar la consulta), lo que dañaría el rendimiento ya que la mayoría de los servidores prefieren almacenar en caché los planes de consulta y los resultados provisionales. seguir cambiando.

O debería utilizar una base de datos con una de cada mesa y sólo tiene que añadir un campo de identificación de la compañía a las tablas?

Es posible que desee hacer esto si desea tener algún tipo de modelo escalable para sus clientes. Si bien aprovisionar una nueva base de datos para cada cliente le brinda mucha flexibilidad, también implica costos y complejidad. Debe crear una nueva programación de copia de seguridad, tener un modelo de ciclo de vida para tratar con clientes caducados, etc.

Entonces, podría decir que los clientes de "prueba gratuita" y "bronce" están agrupados en una única base de datos, utilizando la compañía id para separarlos; los usuarios "plateados" obtienen su propia base de datos (pero aún conserva el campo customer_id en el esquema, para que no tenga que cambiar las consultas entre dos niveles de clientes), y los clientes "gold" obtienen su propio servidor de base de datos.

Hice algo similar hace algunos años en una empresa de SaaS, y los clientes suelen estar contentos de tener una ruta de actualización en la infraestructura (léase: rendimiento y resistencia), así como las características.