Utilizzo di un servizio di directory invece di un database

Uso anche Active Directory sul mio sito web aziendale. Uno dei vantaggi è stato che non solo il nostro personale ha condiviso per il sito Web lo stesso account che utilizzano per connettersi a Windows, ma anche i clienti stessi potrebbero utilizzare diversi servizi al di fuori del sito stesso (come essere in grado di connettersi ad alcuni dei nostri server tramite Remote Desktop o utilizza SVN, che si basa su Active Directory).

Avere un'unica fonte di verità è sempre bello, anche per gli account degli utenti. Non immagino di dover cambiare una volta al mese la mia password di Windows, la mia password SVN, la password sul sito web aziendale e altre cinque o sei password che verrebbero visualizzate se usassimo fonti di dati diverse per ciascuno di quei sistemi.

Detto questo, posso vedere alcuni inconvenienti di questo approccio:

1. Se non si beneficiano, come nel mio caso, di diversi sistemi disparati collegati a una singola Active Directory, non vedo perché si scegliesse AD invece di un database SQL.

2. Un errore nella configurazione e qualsiasi utente registrato può accedere a qualsiasi macchina. Questo è rischioso.

3. Immaginerei che Active Directory sia più lenta di un database SQL medio . Detto questo, non ho fatto alcuna profilazione e benchmarking per avere alcuna prova di questa asserzione.

4. Active Directory è un albero, con lo scopo di organizzare e raggruppare entità e assegnare loro le autorizzazioni. Per un normale sito Web che richiede l'autenticazione, tale struttura è eccessiva. Una semplice tabella piatta è in gran parte sufficiente.

5. L'uso di Active Directory non è una cosa normale per un sito web. Quando inizi a svilupparlo, incontri molti problemi che non sono ovvi da risolvere, incluso il famoso errore che dice che Active Directory è riluttante ad elaborare la tua richiesta, perché ... beh, è in una brutta situazione umore oggi. Anche l'unit test della soluzione non è semplice, e ci sono cose che possono essere facilmente perse, come i personaggi che dovresti evitare (dato che ci sono due liste distinte) per evitare l'iniezione di AD.

6. Immagino che potrebbero esserci degli svantaggi quando si tratta di configurazione e implementazione, anche se personalmente, non ne ho mai incontrati.

I server LDAP sono spesso utilizzati in un ambiente Web e spesso i dati dell'utente. Il Single Sign-On è quasi sempre supportato da un archivio dati LDAP. Quello dovrebbe sempre usare un database (relazionale) piuttosto che altri archivi dati è ... scadente.

La chiave con qualsiasi archivio dati è quella che utilizza quella più appropriata per i dati. A volte i dati si adattano meglio in un database tradizionale, a volte è meglio in un archivio dati in stile nosql, altre volte è una directory. Si dovrebbe usare l'archivio dati appropriato per i dati.

La cosa su cui LDAP eccelle è la ricerca veloce di dati che cambiano raramente. Tornando ai dati dell'utente (ad esempio), email, password, nome e ruoli cambiano raramente.

Allo stesso modo, i dati memorizzati nella cache spesso si adattano bene a una directory in cui si calcolano i dati e quindi si caricano (che viene quindi letto frequentemente).

Le directory, tuttavia, non amano frequentemente l'aggiornamento dei dati. È un compromesso: puoi ottimizzare le letture se penalizzi le scritture. Ricostruire gli indici al volo non è qualcosa che LDAP fa bene quando lo si confronta con un database relazionale.

Le transazioni (e quanto bene) funzionano sono ancora in flusso all'interno di LDAP. Se si desidera che più aggiornamenti siano una singola operazione atomica, ciò potrebbe causare problemi.

L'integrità referenziale (chiavi esterne, vincoli univoci) non esiste all'interno di LDAP. Allo stesso modo, se è ciò di cui hai bisogno, potresti trovarlo difficile.

Mentre un potrebbe comprimere i dati JSON in un campo all'interno di LDAP, LDAP stesso non tenta di eseguire le strutture di dati presenti in altri database.

Se si sta eseguendo un numero non occasionale di scritture o aggiornamenti (e quindi di impatto sulle prestazioni), "join" di dati anziché filtri o maggiore coerenza rispetto alle offerte di replica LDAP, è possibile che l'archivio dati LDAP non sia appropriato .

Ma come archivio dati per cose che raramente cambia, è spesso uno dei migliori.

Una directory è un database, sebbene non si usi SQL per accedere. Quindi, chiamalo semplicemente un database NoSQL e sei di nuovo fantastico!

L'unico vincolo sarebbe che su una directory le strutture dati (lo schema) sono fisse, quindi potrebbero non essere adeguate per la maggior parte dei casi. Ma se puoi esprimere lo spazio del tuo problema in quella struttura, allora potrebbe essere altrettanto buono.