Come dividere la responsabilità tra LDAP e RDBMS

Question

Sono uno sviluppatore principale di un progetto che sta creando applicazioni Web per l'offerta SaaS della mia azienda. Attualmente stiamo utilizzando LDAP per archiviare dati utente come ID, password, dettagli contanct, preferenze e altri dati specifici dell'utente.

Una delle applicazioni che stiamo sviluppando è un servizio di reporting che raccoglierà e presenterà informazioni di gestione ai nostri utenti finali. Ovviamente questo servizio richiederà un RDBMS ma dovrà anche accedere ai dati dell'utente memorizzati in LDAP.

A mio avviso, abbiamo due opzioni di implementazione di base:

1. Duplicazione dei dati utente sia in LDAP che in RDBMS.
2. Avere il servizio di reportistica di accedere a LDAP ogni volta che ha bisogno dei dati dell'utente.

Sebbene la duplicazione dei dati (e l'implementazione dei meccanismi per realizzare ciò) come suggerito nell'opzione 1 sembri la strada sbagliata, la mia sensazione è che l'opzione 2 non funzionerebbe abbastanza bene (come si 'uniscono' i dati LDAP a Dati RDBMS con la stessa efficienza di una pura implementazione RDBMS?).

Ho trovato una domanda correlata ma non sono ancora sicuro di quale approccio adottare. Sarei interessato a vedere cosa pensavano le persone di entrambe le opzioni o forse di altre opzioni.

Answer 1

Perché pensi che duplicare i dati sarebbe la strada sbagliata? Gli strumenti di reporting (basati sul Web e non) sono principalmente basati su RDBMS, quindi qualsiasi combinazione e introduzione introdurrà complessità non necessarie. È probabile che i rapporti debbano essere modificati abbastanza frequentemente (per esperienza), quindi vuoi che siano il più semplici possibile. È improbabile che i dati che memorizzi sugli utenti cambino il suo formato molto spesso, quindi una volta che hai la tua funzione di importazione attiva, non dovrai toccarla di nuovo.

L'unico ostacolo che posso vedere è la latenza: come assicurate che la vostra copia RDBMS sia aggiornata? Potrebbe essere necessario assicurarsi che il codice di aggiornamento venga scritto in entrambe le destinazioni. Personalmente, inoltre, non utilizzerei necessariamente LDAP per preferenze personali specifiche dell'applicazione: LDAP non è in grado di gestire le transazioni, quindi cosa succede quando i dati vengono aggiornati da diverse direzioni? (Naturalmente la transazionalità è anche un problema nel consentire ai programmi di aggiornamento di scrivere in entrambi i negozi ...) Preferirei che RDBMS fosse il master per la maggior parte dei dati e che LDAP si preoccupasse solo di identità, credenziali e diritti, che raramente vengono modificati e solo per una serie di scopi. Per quanto mi riguarda, la capacità di LDAP di gestire i dati gerarchici non è poi un punto di forza.

La duplicazione dei dati non è sempre negativa, specialmente quando gli scenari di utilizzo sono abbastanza diversi.