Servizio di directory: differenze tra le versioni

Versione delle 14:24, 2 dic 2013

Versione delle 14:28, 2 dic 2013

Riga 10:

Ne consegue che le directory non sono adatte per immagazzinare informazioni aggiornate di frequente. Ad esempio, il numero di processi in coda in fase di [[Stampa (processo)|stampa]] non va memorizzato in una directory, visto che per offrire un dato accurato il numero deve essere aggiornato continuamente. La directory può invece contenere l’[[indirizzo]] di una stampante remota che è inserita nel processo di stampa; una volta trovata la stampante con una ricerca nella directory, si può ottenere poi il numero di processi in attesa. L’informazione nella directory (indirizzo della stampante) è statica, mentre il numero richiesto è dinamico e quindi non adatto per stare in una directory.

Un’altra differenza tra directory e database relazionali è che la maggior parte delle implementazioni di directory non supporta le [[transazione (database)|transazioni]]. Sono comunque supportate nel [[Lightweight Directory Access Protocol|LDAP]], anche se sono limitate a transazioni tra directory LDAP e non includono altre transazioni, come operazioni tra database. Le transazioni sono operazioni atomiche, cioè che devono essere eseguite interamente o non eseguite per niente, come ad esempio avviene per le operazioni bancarie di trasferimento di denaro. I tradizionali database relazionali di solito supportano queste transazioni, che però complicano la loro implementazione.

Un’altra importante differenza sta nel metodo di accesso alle informazioni. La maggior parte dei database relazionali supporta un metodo d’accesso potente e standardizzato che è [[SQL]]. SQL permette aggiornamenti e interrogazioni elaborati a discapito delle dimensioni del programma e della complessità dell’applicazione. Le directory invece, in particolare le directory LDAP, usano un protocollo di accesso semplificato e ottimizzato che può essere usato in applicazioni snelle e relativamente semplici. Visto che le directory non hanno l’intento di fornire lo stesso numero di funzioni di un tradizionale database relazionale, possono essere ottimizzate per consentire a più applicazioni di accedere ai dati in grandi sistemi distribuiti nel modo più rapido possibile.