LDAP est un protocole. Après les serveurs d'annuaire parlant le LDAP sont pléthores (OpenLDAP, ActiveDirectory, Samba4, 389 Directory Server (Fedora), …). Le protocole LDAP permet de faire des requêtes genre "je veux tous les objets ayant le type X ou le type Y, ayant l'attribut Z présent, ayant l'attribut V = blabla ou V = blibli. Retournes-moi les attributs A, B et C de ces objets. Applique cette recherche sur les enfants directes de l'entrée E". Je crois que ce qui agrégation et OLAP c'est couvert par les méthodes de recherches. Ensuite les objets LDAP doivent avoir un schéma, mais peuvent avoir autant de schéma que l'on souhaite. Il suffit juste d'en ajouter. Et c'est pas un truc définitif. On créer un objet avec un schéma et six mois plus tard on rajoute un schéma et chaque objet, finalement, à son propre jeu de schéma. Bien entendu il y a les références vers des autres objets.
Et tout le côté orienté objet des schémas avec l'héritage (mais pas multiple) rend le tout très intéressant et les options des attributs, la multiplicité des attributs (un objet peut avoir 0 ou N attribut (le schéma peut forcer un attribut à être 0 ou 1)).
Après tu as encore des trucs comme les entrées ayant une durée de vie. La sécurité avec des règles comme "l'attribut X n'est accessible que si le niveau de sécurité est plus grand que Z (ce niveau correspondra à une recherche faites depuis une connexion TLS authentifiée client et serveur), … Après il y a bien entendu toute la partie d'extension du protocole et tellement d'autres choses …
Par contre c'est très, très mal utilisé en général. Tu prends déjà tous les codes php sont dramatiques : tu n'as pas de connexion persistante possible (donc les résultats paginés tu l'as dans l'os), il te manque l'accès à toute une partie du protocole (les extensions et j'ai proposé un patch), tu n'as pas accès à toutes les requêtes asynchrones et bon, ayant essayé de patcher php-ldap, le code du module me fait peur (et le corriger, j'ai passé pas mal de temps dessus et là j'ai plus le temps, mais il faudrait réécrire complètement parce 1) pas possible de garder les codes existants fonctionnelles 2) l'arrivée d'horreur comme ldap_control_paged_result_response qui normalement est juste une extension que l'on passe avec la requête ldap_search).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs (DN, TLS ou pas, …) alors que normalement c'est 1) requête DNS pour savoir où se trouve l'annuaire 2) requête sur le Root DSE de l'annuaire pour savoir ce qu'il a comme schéma, supporte comme sécurité, comme version de TLS, sa racine, ses extensions, … bref tout ce que tu souhaites savoir et 3) tu peux intégrer un nouveau schéma directement par une requête au bonne endroit (le bonne endroit étant donné par l'annuaire).
Avec un annuaire LDAP, tu te poses moins de question quant à la création de ta base de données. Alors qu'avec du relationnel tu vas te poser des questions sur "comment stocker", avec LDAP une fois que tu as répondu à "quoi stocker" tu as ta base prête. Il reste juste à écrire le schéma (ce que tu fais aussi sur une base relationnelle) et utiliser.
Et pour finir, LDAP est certe optimisé en lecture, mais concrètement les cas où tu as la lecture/écriture avec un ratio 1/1 sont rares. Généralement c'est plus proche du 90/10. Et quand tu regardes les performances du dernier né dans les backend de OpenLDAP et face à InnoDB (en gros le backend mdb de OpenLDAP atteint des performances proches de celle de Memcached et lecture/écriture et est même plus rapide en multi-thread car c'est un backend lockless.
Bon dans un système de type transaction comme les banques, une base relationnelle est la seule réponse valable (du moins pour stocker les transations).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 10.
LDAP est un protocole. Après les serveurs d'annuaire parlant le LDAP sont pléthores (OpenLDAP, ActiveDirectory, Samba4, 389 Directory Server (Fedora), …). Le protocole LDAP permet de faire des requêtes genre "je veux tous les objets ayant le type X ou le type Y, ayant l'attribut Z présent, ayant l'attribut V = blabla ou V = blibli. Retournes-moi les attributs A, B et C de ces objets. Applique cette recherche sur les enfants directes de l'entrée E". Je crois que ce qui agrégation et OLAP c'est couvert par les méthodes de recherches. Ensuite les objets LDAP doivent avoir un schéma, mais peuvent avoir autant de schéma que l'on souhaite. Il suffit juste d'en ajouter. Et c'est pas un truc définitif. On créer un objet avec un schéma et six mois plus tard on rajoute un schéma et chaque objet, finalement, à son propre jeu de schéma. Bien entendu il y a les références vers des autres objets.
Et tout le côté orienté objet des schémas avec l'héritage (mais pas multiple) rend le tout très intéressant et les options des attributs, la multiplicité des attributs (un objet peut avoir 0 ou N attribut (le schéma peut forcer un attribut à être 0 ou 1)).
Après tu as encore des trucs comme les entrées ayant une durée de vie. La sécurité avec des règles comme "l'attribut X n'est accessible que si le niveau de sécurité est plus grand que Z (ce niveau correspondra à une recherche faites depuis une connexion TLS authentifiée client et serveur), … Après il y a bien entendu toute la partie d'extension du protocole et tellement d'autres choses …
Par contre c'est très, très mal utilisé en général. Tu prends déjà tous les codes php sont dramatiques : tu n'as pas de connexion persistante possible (donc les résultats paginés tu l'as dans l'os), il te manque l'accès à toute une partie du protocole (les extensions et j'ai proposé un patch), tu n'as pas accès à toutes les requêtes asynchrones et bon, ayant essayé de patcher php-ldap, le code du module me fait peur (et le corriger, j'ai passé pas mal de temps dessus et là j'ai plus le temps, mais il faudrait réécrire complètement parce 1) pas possible de garder les codes existants fonctionnelles 2) l'arrivée d'horreur comme ldap_control_paged_result_response qui normalement est juste une extension que l'on passe avec la requête ldap_search).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs (DN, TLS ou pas, …) alors que normalement c'est 1) requête DNS pour savoir où se trouve l'annuaire 2) requête sur le Root DSE de l'annuaire pour savoir ce qu'il a comme schéma, supporte comme sécurité, comme version de TLS, sa racine, ses extensions, … bref tout ce que tu souhaites savoir et 3) tu peux intégrer un nouveau schéma directement par une requête au bonne endroit (le bonne endroit étant donné par l'annuaire).
Avec un annuaire LDAP, tu te poses moins de question quant à la création de ta base de données. Alors qu'avec du relationnel tu vas te poser des questions sur "comment stocker", avec LDAP une fois que tu as répondu à "quoi stocker" tu as ta base prête. Il reste juste à écrire le schéma (ce que tu fais aussi sur une base relationnelle) et utiliser.
Et pour finir, LDAP est certe optimisé en lecture, mais concrètement les cas où tu as la lecture/écriture avec un ratio 1/1 sont rares. Généralement c'est plus proche du 90/10. Et quand tu regardes les performances du dernier né dans les backend de OpenLDAP et face à InnoDB (en gros le backend mdb de OpenLDAP atteint des performances proches de celle de Memcached et lecture/écriture et est même plus rapide en multi-thread car c'est un backend lockless.
Bon dans un système de type transaction comme les banques, une base relationnelle est la seule réponse valable (du moins pour stocker les transations).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell