So als Gedankenspiel mal ein paar Vor- und Nachteile:
LDAP ist ein standardisiertes Protokoll (RFC 4511). Die Protokolle zwischen Datenbankclient und -server sind das in der Regel nicht.
Es gibt verschiedene LDAP-Implementierungen, die (sofern sie dem Standard entsprechen) beliebig ausgetauscht und ggf. miteinander kommunizieren können. Mach das mal mit relationalen Datenbanken. ;)
LDAP ist ein Verzeichnisdienst und somit auf Lookups optimiert. Relationale Datenbanken sind das nicht.
Ein LDAP-Verzeichnis lässt sich verhältnismäßig einfach replizieren. Bei einer relationalen Datenbank hängt das stark vom konkreten Produkt ab.
Relationale Datenbanken lassen sehr komplexe Anfragen zu (eben durch SQL).
Ganz wichtig ist auch der Unterschied in der Struktur. Mit LDAP kann eine Baumstruktur aufgebaut werden. Dies ist mit Datenbanken zwar auch möglich, aber umständlich und nicht optimiert.
Mal so rein ins blaue geschossen meine Vorteile für LDAP.
Ich muss mir keine so großen Gedanken um die Struktur der Daten machen sofern man sich alle Programme an ein paar Schemas halten. Mich nervt es total, wenn ich einem Programm bei gefühlten 370 Optionen sagen muss wo es die Daten im LDAP findet, was bei eine Datenbank wieder der Fall wäre. Zumindest in den Fällen die ich kenne (was nicht so viele sind gebe ich zu). Wenn es Schema X im LDAP gibt dann greift Programm Y allein mit den Verbindungsinformationen auf alles selbst zu. Theoretisch.
Und viele Anwendungen unterstützen eine Authentifizierung gegen LDAP, aber nicht gegen eine Datenbank, d.h. wenn Du viele Anwendungen anbinden willst, dann stellt sich die Frage fast nicht.
zu beachten ist auch die Größenordnung und Struktur der Nutzung. LDAP ist für das Lesen optimiert und gerade bei vielen und konkurrierenden Zugriffen deutlich im Vorteil.
Bei wenigen Abfragen und ggf. auch Schreibzugriffen in ähnlicher Größenordnung wie das Lesen ist eine Datenbank evtl. sinnvoller. Vor allem, wenn das LDAP nur eine weitere Schicht ohne konkreten Vorteil für den Einsatzzweck ist. Wenn es z.B. nur darum geht dass 3 Dienste Benutzerdaten abfragen.
Mehr Informationen zum Einsatzszenario wären sinnvoll.
Ehm… ich denke die Fragestellung ist hier die Falsche. Es müßte wohl eher LDAP oder SQL? lauten. Rein technisch spricht nichts dagegen die Daten die per LDAP abgefragt werden in einer Datei oder Dateisystembasiert zu hinterlegen. Technisch sinnvoller wäre aber das hinterlegen der Daten in einer klassischen Datenbank. Dank der hierachischen Abfragemöglichkeit von LDAP eigenen sich aber nicht alle Datenbanken gleich gut.
Dank diverser vorahndener Schemata und Schematatemplates eignet sich LDAP wohl besser für die klassischen administrative Allerweltsdinge. (Authentifizierungen, User/Group Policies, Addressbücher, etc.).
Dafür ständing eigene Module (PAM, E-Mail Client, etc.) zu entwickeln um per SQL ‘ne DB mit eigenemen Schema abzufragen ist vermutlich etwas aufwändig.
Also ich würde LDAP jedem DBMS vorziehen. Zum einen aus den oben genannten Gründen und zum anderen weil ich es seit vielen Jahren erfolgreich nicht nur zur Userauthentifizierung einsetze ( Apache Vhosts, PHP Configs, Bind Configs, Mailrouting, FTP uvm.). Zudem habe ich einige Schemas geschrieben und wir entwickeln gerade an einem Management System für Hoster, Rechenzentren etc.). Dadurch das LDAP Klassen in sogut wie jeder Sprache verfügbar sind und die Verwaltung von LDAP sehr einfach zu realisieren ist, ziehe ich dies jedem meterlangen SQL Query vor :-)
Einfache Antwort: Wenn es die Vorgaben erfordern.
So als Gedankenspiel mal ein paar Vor- und Nachteile:
LDAP ist ein standardisiertes Protokoll (RFC 4511). Die Protokolle zwischen Datenbankclient und -server sind das in der Regel nicht.
Es gibt verschiedene LDAP-Implementierungen, die (sofern sie dem Standard entsprechen) beliebig ausgetauscht und ggf. miteinander kommunizieren können. Mach das mal mit relationalen Datenbanken. ;)
LDAP ist ein Verzeichnisdienst und somit auf Lookups optimiert. Relationale Datenbanken sind das nicht.
Ein LDAP-Verzeichnis lässt sich verhältnismäßig einfach replizieren. Bei einer relationalen Datenbank hängt das stark vom konkreten Produkt ab.
Relationale Datenbanken lassen sehr komplexe Anfragen zu (eben durch SQL).
Ganz wichtig ist auch der Unterschied in der Struktur. Mit LDAP kann eine Baumstruktur aufgebaut werden. Dies ist mit Datenbanken zwar auch möglich, aber umständlich und nicht optimiert.
Mal so rein ins blaue geschossen meine Vorteile für LDAP.
Ich muss mir keine so großen Gedanken um die Struktur der Daten machen sofern man sich alle Programme an ein paar Schemas halten. Mich nervt es total, wenn ich einem Programm bei gefühlten 370 Optionen sagen muss wo es die Daten im LDAP findet, was bei eine Datenbank wieder der Fall wäre. Zumindest in den Fällen die ich kenne (was nicht so viele sind gebe ich zu). Wenn es Schema X im LDAP gibt dann greift Programm Y allein mit den Verbindungsinformationen auf alles selbst zu. Theoretisch.
Und viele Anwendungen unterstützen eine Authentifizierung gegen LDAP, aber nicht gegen eine Datenbank, d.h. wenn Du viele Anwendungen anbinden willst, dann stellt sich die Frage fast nicht.
zu beachten ist auch die Größenordnung und Struktur der Nutzung. LDAP ist für das Lesen optimiert und gerade bei vielen und konkurrierenden Zugriffen deutlich im Vorteil.
Bei wenigen Abfragen und ggf. auch Schreibzugriffen in ähnlicher Größenordnung wie das Lesen ist eine Datenbank evtl. sinnvoller. Vor allem, wenn das LDAP nur eine weitere Schicht ohne konkreten Vorteil für den Einsatzzweck ist. Wenn es z.B. nur darum geht dass 3 Dienste Benutzerdaten abfragen.
Mehr Informationen zum Einsatzszenario wären sinnvoll.
Hinter LDAP steckt auch eine Datenbank, nämlich die von Oracle gekaufte Berkeley DB, LDAP ist eine Sammlung von Methoden, die darauf aufsetzt.
Bei den anderen Pluspunkten stimme ich aber zu:
- LightWeight
- Standardisiert
- Replikation
- Hierarchisch
(Wobei das ein anderer Aufsatz für eine Datenbank auch leisten könnte).
Ehm… ich denke die Fragestellung ist hier die Falsche. Es müßte wohl eher LDAP oder SQL? lauten. Rein technisch spricht nichts dagegen die Daten die per LDAP abgefragt werden in einer Datei oder Dateisystembasiert zu hinterlegen. Technisch sinnvoller wäre aber das hinterlegen der Daten in einer klassischen Datenbank. Dank der hierachischen Abfragemöglichkeit von LDAP eigenen sich aber nicht alle Datenbanken gleich gut.
Dank diverser vorahndener Schemata und Schematatemplates eignet sich LDAP wohl besser für die klassischen administrative Allerweltsdinge. (Authentifizierungen, User/Group Policies, Addressbücher, etc.).
Dafür ständing eigene Module (PAM, E-Mail Client, etc.) zu entwickeln um per SQL ‘ne DB mit eigenemen Schema abzufragen ist vermutlich etwas aufwändig.
Also ich würde LDAP jedem DBMS vorziehen. Zum einen aus den oben genannten Gründen und zum anderen weil ich es seit vielen Jahren erfolgreich nicht nur zur Userauthentifizierung einsetze ( Apache Vhosts, PHP Configs, Bind Configs, Mailrouting, FTP uvm.). Zudem habe ich einige Schemas geschrieben und wir entwickeln gerade an einem Management System für Hoster, Rechenzentren etc.). Dadurch das LDAP Klassen in sogut wie jeder Sprache verfügbar sind und die Verwaltung von LDAP sehr einfach zu realisieren ist, ziehe ich dies jedem meterlangen SQL Query vor :-)