Cómo dividir la responsabilidad entre LDAP y RDBMS

Question

Soy un desarrollador líder en un proyecto que está creando aplicaciones web para la oferta SaaS de mi empresa. Actualmente estamos usando LDAP para almacenar datos de usuario como ID, contraseñas, detalles de contacto, preferencias y otros datos específicos del usuario.

Una de las aplicaciones que estamos creando es un servicio de informes que recopilará y presentará información de gestión a nuestros usuarios finales. Obviamente, este servicio requerirá un RDBMS, pero también necesitará acceder a los datos del usuario almacenados en LDAP.

Tal como lo veo que tienen una de dos opciones de implementación básicas:

1. de datos de usuario duplicados en ambos LDAP y RDBMS.
2. Haga que el servicio de informes acceda a LDAP siempre que necesite datos de usuario.

Aunque duplicar datos (e implementar los mecanismos para que esto ocurra) como se sugiere en la opción 1 parece ser el camino equivocado, mi intuición es que la opción 2 no funcionaría lo suficiente (¿cómo 'unirse'? ¿Datos LDAP a datos RDBMS tan eficientemente como una implementación pura de RDBMS?).

Encontré un related question pero todavía no estoy seguro de qué enfoque tomar. Me interesaría ver qué pensaban las personas sobre cualquiera de las opciones o quizás sobre otras opciones.

Answer 1

¿Por qué crees que duplicar datos sería el camino equivocado? Las herramientas de informes (basadas en la web y de otro tipo) se basan principalmente en RDBMS, por lo que cualquier mix'n'match introducirá complejidades innecesarias. Es probable que sea necesario cambiar los informes con bastante frecuencia (por experiencia), por lo que desea que sean lo más simples posible. Es poco probable que los datos que almacena sobre los usuarios cambien su formato muy a menudo, por lo que una vez que tenga activada su función de importación, no necesitará volver a tocarla.

El único obstáculo que puedo ver es la latencia: ¿cómo se asegura de que su copia de RDBMS esté actualizada? Es posible que deba asegurarse de que su código de actualización se escriba en ambos destinos. Personalmente, tampoco usaría LDAP necesariamente para preferencias personales específicas de la aplicación: LDAP no puede manejar transacciones, entonces, ¿qué sucede cuando los datos se actualizan desde varias direcciones? (La transaccionalidad también es un problema para dejar que los actualizadores escriban en ambas tiendas ...) Prefiero dejar que el RDBMS sea el maestro para la mayoría de los datos, y dejar que LDAP se preocupe solo por la identidad, las credenciales y las autorizaciones, que rara vez se modifican y solo para un conjunto de propósitos. Para mí, la capacidad de LDAP para manejar datos jerárquicos no es un gran punto de venta.

La duplicación de datos no siempre es mala, especialmente cuando los escenarios de uso son lo suficientemente diferentes.