asp.net - resueltos - Para varios inquilinos o no para varios inquilinos

johnson r 2012 págs 32 62 (8)

Tengo que tomar una decisión difícil sobre el diseño de la base de datos con respecto al alquiler múltiple para el creciente número de sucursales del CRM basado en la web de mi cliente, que mantengo activamente.

Tomé la decisión desde el principio para usar aplicaciones separadas con bases de datos separadas para cada sucursal, porque era la forma más sencilla de atender tres ramas diferentes con datos dispares y requisitos de código. También quería evitar administrar las ID de inquilino en cada consulta, como tenía que hacer con la aplicación Classic ASP ( cringe ) heredada que construí en 2007 ... el horror.

Pero ahora los requisitos de datos para las sucursales convergen y, a medida que la empresa se expande, necesito poder implementar nuevas sucursales rápidamente y compartir SKU de productos globales.

Como las tablas y las vistas son las mismas para todas las sucursales y ahora hay mejores herramientas ORM disponibles para gestionar las aplicaciones de múltiples usuarios, me pregunto si sería mejor tener una base de datos compartida para varias sucursales.

Consideraciones para una base de datos centralizada:

SKUs globales del producto
Solicitudes de inventario simplificadas
Más fácil de respaldar
Implementar una vez en lugar de por cada rama

Consideraciones contra una base de datos centralizada:

Es más fácil diferenciar los requisitos de sucursal con DB separados
Despliegue modular (una rama inactiva no rompe todo)
Más difícil de administrar y desarrollar para DB compartida
Tengo que volver a diseñar la numeración de la factura (secuencia generada por la semilla)
Menos cláusulas WHERE en todas partes
Restaurar una rama rota tiene muchas implicaciones para otras ramas

Es poco probable que haya más de 10 sucursales. En este momento hay 3.

Desarrolladores con experiencia en el mundo real en esta área, ¿qué harías en mi situación? Mantenga las aplicaciones y los DB separados, o combínelos en un solo sistema gigante.

Editar: Gran artículo de Microsoft sobre pro y contras multi-tenancy. Debo señalar que el aislamiento de datos entre sucursales no es un problema importante.

Bueno, si la tendencia es compartir información y datos entre diferentes sucursales, probablemente sea mejor tener una base de datos central.

De lo contrario, los aros que tendrá que atravesar para lograr la capacidad de compartir datos serán mucho peores que las cláusulas WHERE adicionales necesarias para una base de datos compartida.

Por supuesto, podría tener una base de datos por sucursal y una base de datos adicional (una cuarta base de datos a partir de ahora) como almacenamiento centralizado para la información que debe compartirse. Aunque tendrías que ver si la complicación excesiva hace que esta sea la mejor o la peor solución de ambos mundos :)

Honestamente, esta es una pregunta comercial. O bien podrá entregar funciones más personalizadas a un grupo de usuarios más pequeño en una configuración de múltiples usuarios pero con más gastos generales de TI. Es decir, necesitará más personas y hardware (la gerencia lee esto: dinero) pero ofrece una mayor flexibilidad.

Si se encuentra en una situación de Borg GIGANTE, entonces reduce los gastos generales de TI (de nuevo, personas y cosas, a dinero de gestión) pero los usuarios finales deben absorber menos flexibilidad en su software. Todos los errores son problemas para todos los usuarios, por lo que los más grandes son golpeados rápidamente. Sin embargo, las nuevas funciones también afectan a todos los usuarios, por lo que suceden más lentamente.

Si usted personalmente tiene el jugo para hacer esta llamada y el negocio solo tiene que escuchar lo que dice, o puede empujar a la gerencia de una forma u otra, le sugiero que se haga una serie de preguntas sobre el escenario que prefiera:

A) ¿Desea tener más personas gestionando esto y compartiendo salario / responsabilidad B) A su leal saber y entender, ¿pronto habrá un cuarto grupo de usuarios? C) ¿Cuánto tiempo quieres permanecer en esta empresa?

Si respondes que sí a los dos primeros, entonces probablemente quieras tener varios inquilinos.

La descentralización de la OMI se está convirtiendo en un inquilino de diseño escalable y mantenible. La única base de datos centralizada que utilizo es para la seguridad de la autenticación, que actualmente estoy convirtiendo en una base de datos descentralizada para la autorización. Por lo tanto, toda la autorización puede permanecer en el mismo límite que la aplicación se encuentra físicamente sin cruces de red ya que la autorización no es un gran candidato para el almacenamiento en caché.

Leyendo que está específicamente interesado en múltiples ramas de la misma aplicación en lugar de aplicaciones realmente dispares, parece una gran opción construir su base de datos en torno a un proceso de siembra (Entity Framework lo admite) que le permitiría implementar su nuevo código de sucursal para ASP.NET, y luego durante la creación inicial de la base de datos que las tablas se crearon físicamente, sondear el servidor "bendecido" y volcar todos los datos necesarios al servidor perimetral.

Después de esto, necesitaría alguna configuración de replicación si se están agregando productos nuevos al almacén de datos principal y se espera que lleguen a cada tienda de borde. Puede lograr esto con la replicación directa de su base de datos o ver herramientas como el marco Microsoft Sync.

Muerde la bala y combínalos. Agregue su ID de inquilino donde debe estar y cambie sus consultas.

Para las personalizaciones, busque en una arquitectura de tipo de complemento que le permita implementar pantallas específicas para clientes particulares.

Tenemos un producto de software que está construido de esa manera. A veces se implementa en un sitio de cliente, a veces lo hospedamos. Para todos los efectos, es un orden de magnitud más fácil tratar con una base de código única que tiene extensiones específicas de cliente que tratar con múltiples ramas del código.

Por un lado, cuando solucionamos un problema, lo solucionamos para todos. Claro, si lo rompemos, lo rompemos para todos, pero para eso sirven las pruebas unitarias. Y es muchísimo más fácil mantener un conjunto de pruebas unitarias contra una base de código que mantenerlas en múltiples ramas.

Hemos estado haciendo varios inquilinos durante más de 10 años y ni una sola vez lo he hecho. En términos generales, las consultas no son tan diferentes si ya está consciente de la seguridad al verificar que la persona que recupera el registro puede obtenerlo.

No estoy de acuerdo con los problemas planteados por Corbin. El que está alrededor del control de versiones ya debería manejarse teniendo una estructura de seguridad basada en atributos en su lugar. De esa manera puede activar / desactivar cosas a través de la configuración de usuario o inquilino. Además, me parece muy raro que el cliente A no quiera la misma característica nueva que solicitó el cliente B.

El segundo sobre la mezcla de datos tampoco es un problema. Solo mire en salesforce.com o en cualquiera de los otros sitios a gran escala. Absolutamente usan una arquitectura de múltiples inquilinos y, a juzgar por la cantidad de clientes que los utilizan, esto no parece ser un problema. Lo principal aquí es poder garantizar a sus clientes que sus datos estén seguros.

Puede pensar hoy que solo tendrá unos pocos clientes, pero dentro de unos años podrá darse cuenta de que el producto tiene el potencial de venderse a cientos de clientes. Si eso sucede, lamentará haber utilizado un enfoque de inquilino único.

Compare los costos de:

Conversión de un sistema de producción de un solo inquilino a multi-tenant donde las bases de datos se llenan con los datos del cliente
Desarrollar un sistema multi-inquilino a pesar de pensar que no necesitará los beneficios

Convertir un sistema de producción es una tarea desalentadora y muy costosa. Usar el segundo enfoque puede costarle más inicialmente, pero le brinda una opción muy valiosa para poder agregar más clientes en el futuro a bajo costo. El precio de esa opción podría valer la pena.

Si estamos hablando de CRM, ¿cuáles son las posibilidades de que un cliente esté en múltiples bases de datos? Si existe la más mínima posibilidad de que se le pida que combine los datos de los clientes entre sucursales, definitivamente iría con una base de datos centralizada.

Si habla de 10 sucursales, el multi-arrendamiento parece ser un gran costo con pocos beneficios.

Hay complicaciones con el multi-arrendamiento que no mencionas:

El control de versiones se vuelve difícil. Los clientes X, Y y Z pueden querer una nueva característica, mientras que los clientes A, B y C no la necesitan. Una aplicación multiusuario dificulta la adaptación de todos, especialmente si una característica nueva requiere cambios en el esquema de la base de datos. No es imposible, es simplemente más difícil.
Algunos clientes se sienten incómodos al mezclar sus datos en las mismas tablas que otros clientes. A pesar de que sabemos mejor, se siente como un riesgo de seguridad para ellos. Los departamentos legales lo odian. Además, si alguna vez vuelcas datos sin formato para un cliente, una base de datos compartida requiere precaución.

Puede eliminar algunos de sus puntos débiles con mejores prácticas:

Automatice la implementación. Esto debería facilitar agregar un cliente nuevo o actualizar / degradar un cliente existente. El mantenimiento de la base de datos (copias de seguridad, índices de reconstrucción) también debe configurarse automáticamente.
Almacene datos compartidos (códigos de artículo, inventario) en una base de datos central y haga que cada instancia de la aplicación acceda directamente o a través de un servicio.

No me malinterpreten, una de las aplicaciones más interesantes en las que trabajé era multi-tenant. Puede haber grandes beneficios, pero es más probable que los vea con miles de clientes contra diez.

Trabajo en una situación en la que, por motivos regulatorios / legales, tenemos que mantener los datos de cada cliente en una base de datos separada. Sin embargo, hay cierta información que debe compartirse, principalmente relacionada con cosas como una tabla de búsqueda para la cual la URL del cliente corresponde a cada base de datos. Además, un cliente puede elegir tener múltiples bases de datos si desea separar sus datos de alguna manera lógica. Entonces, para cada uno de nuestros productos, realmente tenemos tres tipos de bases de datos:

ApplicationData, que tiene solo unas pocas tablas que contienen información sobre los clientes mismos, como qué base de datos MasterData (ver a continuación) usar cuando se llega por una determinada URL y qué funciones están disponibles para ese cliente. Cada producto tiene solo un ApplicationData, sin importar cuántos clientes diferentes usen ese producto.
MasterData, que contiene información específica del cliente, como usuarios, roles y permisos (en nuestro caso, las tablas que crea aspnet_regsql están aquí). Entre los permisos especificados aquí se encuentran las bases de datos de ClientData disponibles para un usuario determinado (consulte a continuación). El esquema para todas las bases de datos de MasterData (para el mismo producto) es el mismo.
ClientData, que contiene los datos con los que el usuario interactúa. En un producto, estos son datos que el cliente puede buscar en base a una gran cantidad de criterios, crear informes, etc. En otro producto, este contiene los datos dinámicos que un cliente puede cargar para que otros usuarios puedan contactar a las personas para realizar encuestas por teléfono, etc. El esquema para todas las bases de datos de ClientData para el mismo producto es el mismo.

Ahora, una advertencia: en realidad usamos el mismo esquema, y a menudo la misma base de datos real, para MasterData y ClientData. Esto se debe a razones históricas, ya que la capacidad de permitir que un cliente tenga una base de datos de autenticación (MasterData) correspondiente a varias bases de datos de ClientData es una característica relativamente nueva que solo se aplica a uno de nuestros productos. Además, esta estructura simplifica la implementación, ya que la mayoría de los clientes solo usan una base de datos ClientData. Sin embargo, MasterData y ClientData tienen modelos de entidad separados en Entity Framework en nuestros proyectos, y debemos asegurarnos de que no haya relaciones directas entre MasterData y ClientData, como las claves externas.

Esta configuración funciona bastante bien para nosotros. Una ventaja importante es que no hay ningún problema al colocar diferentes bases de datos de ClientData en diferentes servidores. Esto ayuda mucho con el equilibrio de carga y proporciona una forma natural de partición de datos. En esencia, podemos ofrecerle a un cliente con una gran cantidad de datos un servidor de base de datos dedicado si está dispuesto a pagar por ello.

Una cosa más que realmente nos ha ayudado en esta situación son las herramientas de Red Gate, específicamente herramientas como Multi-Script, SQL Source Control y Schema Compare. Cuando actualizamos algo y el esquema cambia, tenemos que implementar los cambios en todas las bases de datos relevantes. Estas herramientas se han pagado más de lo debido en tiempo ahorrado. Tenga en cuenta que no tengo ninguna afiliación con Red Gate que no sea un usuario satisfecho.

Editar: (en respuesta al comentario)

ApplicationData es una base de datos por producto. Los tres productos basados en web que tenemos utilizan el mismo esquema para ApplicationData, ya que registran básicamente los mismos tipos de información. Sin embargo, no hay ninguna razón por la que deba permanecer así. Las bases de datos de ApplicationData están todas en el mismo servidor. Una de las tablas en ApplicationData señala el servidor correcto y el nombre de la base de datos para MasterData del cliente, por lo que MasterData para un cliente dado puede residir en cualquier servidor.

MasterData tiene información de nombre de servidor y base de datos para cada base de datos ClientData, por lo que, de nuevo, las bases de datos pueden residir en cualquier servidor. En la práctica, por ahora, solo tenemos dos servidores de bases de datos de producción para estos productos. El esquema de MasterData es similar por producto, pero no creo que sean exactamente iguales (tendría que verificarlo). Cada cliente tiene su propio MasterData. Si un cliente compra productos múltiples, hay un MasterData para cada producto para ese cliente; los productos interactúan de otras maneras (a través de servicios web, básicamente) si un cliente ha comprado esa característica (o solicita el desarrollo personalizado de dicha función. ClientData para un producto dado siempre tiene el mismo esquema.

Entonces, en resumen:

ApplicationData es por producto y tiene el mismo esquema en cada producto.
MasterData es por cliente para un producto.
Hay una o más instancias de ClientData para un cliente dentro de un producto.

Sí simplifiqué un poco, ya que solo uno de nuestros productos admite varias instancias de ClientData por cliente. Para un segundo producto, eso probablemente se implementará eventualmente. Para un tercer producto, no tendría ningún sentido como característica y probablemente se mantendrá como está.

¡Espero haber respondido a su pregunta!