Arquitectura de software y diseño de base de datos: ¿una base de datos/aplicación web para cada empresa o una base de datos/aplicación web para todas las empresas?

Question

Estoy diseñando una aplicación de base de datos SQL basada en la web desde cero. La aplicación administrará la información para clientes que están en el mismo tipo de industria. En otras palabras, la información (entidades y relaciones entre ellos) con respecto a cada cliente no varía demasiado de uno a otro. Sin embargo, el volumen de la información está dictado por el tamaño de la empresa. La aplicación podría estar alojada en nuestro (s) servidor (es) o en cualquier lugar que el cliente elija.

Mi primera pregunta es: ¿cuáles son los pros y los contras, dadas las siguientes opciones:

• A. gestionar múltiples clientes información de la misma base de datos;
• B. Administre la información de un cliente por base de datos ; por lo que cada cliente tendrá su propia base de datos;

Mi segunda pregunta es: ¿cuáles son los pros y los contras dados los siguientes métodos de implementación?

• A. Cada cliente tiene su propio servidor (nodo);
• B. Utilice unidades RAID grandes con un potente servidor con varios sitios web;

Como las decisiones a estas elecciones afectan mi diseño, me gustaría saber los pros y los contras de diferentes puntos de vista, incluido el mantenimiento, el costo (financieramente y en el tiempo) y la arquitectura para nombrar unos pocos.

Tecnologías utilizadas:

• Base de datos: MS SQL
• Plataforma: ASP.NET
• Idioma: C#

Cualquier comentario o sugerencias son bienvenidos,

Gracias ,

Cullen

Answer 1

No recomendaría dar a cada cliente su propia base de datos. Planeé hacer eso para mi aplicación actual y me hablaron en una única base de datos. Qué bueno, ya que ahora tenemos 300 clientes. ¿Te imaginas administrar 300 bases de datos? ¿Actualizando cada uno cada vez que tienes una actualización? Asegurándose de que cada uno esté actualizado, etc.

Descargo de responsabilidad: En la práctica, en realidad tenemos varias bases de datos. Algunos clientes muy grandes tienen su propia base de datos y otros comparten los restantes. Creo que tal vez 7 bases de datos en total.

Tenemos las bases de datos en un potente servidor SQL. Si tiene varias bases de datos y las coloca en servidores diferentes, corre el riesgo de que algunos servidores estén más ocupados que otros y los clientes pequeños no están utilizando lo suficiente su servidor.

Answer 2

El gran problema es el mantenimiento y la actualización de la aplicación. Si tiene varias instancias ejecutándose, tiene que mantener/actualizar todas estas, esto se convierte en una molestia aún más si se encuentran geográficamente en diferentes áreas.

La tendencia general en la industria del software empresarial ahora es centralizar su aplicación a sus propios servidores y proporcionar software como servicio a sus clientes.

La única razón real que pude ver para tener que ejecutar una aplicación en el sitio de sus clientes es: si está manejando información sensible y la compañía tiene políticas que restringen el almacenamiento remoto de esos datos.

Si le preocupan los costos de hardware, puede buscar servicios de alojamiento en la nube como Amazon s2, Google App Engine y Microsoft Azure.

Answer 3

que realmente quiere revisar la siguiente:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

Es un documento que va sobre los diferentes escenarios de diseño para una arquitectura multi-inquilino. Hay una multitud de cosas a considerar a partir de la partición de datos, la seguridad y el conjunto de habilidades adecuados.

* actualizado con el nuevo enlace

Answer 4

I'd hybrid this. Diseñe para la posibilidad de utilizar bases de datos separadas, pero no separe hasta que haya un claro beneficio de rendimiento.

Diseñe su aplicación para que múltiples clientes puedan existir en la misma base de datos. (es decir, crear una capa de separación entre los datos del cliente). Luego planee que todo esté en una base de datos.

De esta manera, no se sobredimensiona la solución para empezar, pero le da la flexibilidad de derivar clientes de muy alto uso a una base de datos dedicada. Si su base de datos existe con solo un cliente, ¿qué? Esto también ahorrará en costos de servidor para que pueda estar seguro de que está usando la inversión de hardware de una manera razonable antes de agregar más capacidad.

Answer 5

Tengo experiencia ejecutando single-tenant diseño con aproximadamente 40 clientes. Cada cliente tiene archivos de aplicaciones ASP.NET separados y una base de datos SQL Server. Los binarios de núcleo de aplicación son los mismos para cada cliente, pero los clientes también tienen módulos personalizados.

Recomendaría diseñar todo el sistema como multi-tenant primero, pero conservando la opción de ir a single-tenant si es necesario. Creo que la razón por la que elegimos un inquilino individual vino de la demanda del cliente. Muchos de nuestros clientes ejecutan la aplicación dentro de sus intranets.

Nuestro negocio resultó ser muy orientado al cliente, con muchas características personalizadas específicas del cliente. Para esto, las configuraciones de un solo inquilino encajan bien. Pero no creo que sea posible escalar esto a un punto de precio significativamente más bajo y una base de clientes más grande.

Pros

• Bueno para software de negocios. Fácil de personalizar, pero aún así obtener beneficios de la reutilización
• podemos usar una instancias de SQL Express por servidor, siempre y cuando cada base de datos es bajo 4GB
• Las porciones de separación entre los clientes.Por ejemplo, cada cliente puede tener un grupo de aplicaciones de IIS independiente
• de Seguridad en mayor nivel de sistema, no totalmente nivel de aplicación
• versión del software de cliente individual puede congelarse durante períodos largos
• errores por lo general no salen a la superficie en cada cliente
• Las nuevas características se pueden cultivar muy bien en función de la demanda real del cliente. Primeros clientes para una característica son, básicamente, beta-testers

Contras

• malo para software de consumo. No hay que esperar a escala mucho
• Mantenimiento es un trabajo intensivo: actualizaciones, copias de seguridad, la depuración de problemas específicos del cliente ...
• control de calidad es más difícil cuando las versiones son ligeramente diferentes. Problemas inesperados superficie después de las actualizaciones

Answer 6

Rendimiento y etc a un lado, ¿sirve mejor a su cliente para proporcionar bases de datos separadas? ¿Puede este software existir o usarse sin su compañía y/o una licencia?

Por ejemplo, las soluciones simples de comercio electrónico tendrían que proporcionar bases de datos para que el contenido y la base de datos se puedan mover de host a host en caso de que surjan necesidades comerciales. Está utilizando su software para siempre suponiendo que su empresa no falla. Dudo que mi compañía use esa solución, aunque podríamos usar una solución alojada si supiéramos que podríamos alojarla internamente en una fecha posterior.

La seguridad también es otra preocupación. Existe un único punto de falla con una base de datos y si un cliente se ve comprometido y su código tiene una falla, todos los de su cliente estarán potencialmente expuestos.

¿Alguna vez se personalizarán las aplicaciones y, de ser así, una sola base de datos podría causar problemas?