Par contre c'est très, très mal utilisé en général
Effectivement, et pas seulement techniquement (comme dans l'exemple de PHP que tu donnes). Il n'est pas rare que les concepts de LDAP soient mal compris, et que l'annuaire envisagé n'ait pas de sens à être implémenté en LDAP. J'ai en tête des exemples de gens disant « je doit implémenter un annuaire, je fais du LDAP », et créant un schéma de données fortement relationnel, avec des contraintes techniques totalement inadaptées (nombreuses écritures, par exemple). Au final, cela ne marche pas, bien entendu, et ils déclarent que LDAP, c'est mauvais, alors que ce sont eux, qui sont mauvais (oui, oui, carrément…).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs alors que normalement […]
Ça, c'est un truc formidable avec LDAP et sa normalisation poussée (même si cette forte normalisation lui est souvent reprochée). Toute cette auto-découverte qui permet normalement d'interroger n'importe quel annuaire LDAP avec n'importe quel client, c'est vraiment un avantage énorme, mais dont il est rarement question.
Le truc, c'est qu'effectivement les annuaires ont un champ d'utilisation plus étroit que les SGBD[R], et que, de ce fait, personne n'en utilise avant d'y être confronté brutalement. Là où tout le monde a déjà créé N bases de données (SQL etc.) et pense assez bien connaître le principe, les gens ayant un minimum d'expérience pour concevoir un annuaire LDAP sont assez rares. Et les concepts même ne sont habituellement pas maitrisés (ce n'est pas de leur faute, hein ?, c'est juste qu'ils n'ont pas eu l'occasion de savoir). D'où la transposition des principes des SGBD[R] qui conduisent fatalement à de mauvaises expériences.
[^] # Re: Mongueur
Posté par Benoît Bailleux (Mastodon) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 2.
Effectivement, et pas seulement techniquement (comme dans l'exemple de PHP que tu donnes). Il n'est pas rare que les concepts de LDAP soient mal compris, et que l'annuaire envisagé n'ait pas de sens à être implémenté en LDAP. J'ai en tête des exemples de gens disant « je doit implémenter un annuaire, je fais du LDAP », et créant un schéma de données fortement relationnel, avec des contraintes techniques totalement inadaptées (nombreuses écritures, par exemple). Au final, cela ne marche pas, bien entendu, et ils déclarent que LDAP, c'est mauvais, alors que ce sont eux, qui sont mauvais (oui, oui, carrément…).
Ça, c'est un truc formidable avec LDAP et sa normalisation poussée (même si cette forte normalisation lui est souvent reprochée). Toute cette auto-découverte qui permet normalement d'interroger n'importe quel annuaire LDAP avec n'importe quel client, c'est vraiment un avantage énorme, mais dont il est rarement question.
Le truc, c'est qu'effectivement les annuaires ont un champ d'utilisation plus étroit que les SGBD[R], et que, de ce fait, personne n'en utilise avant d'y être confronté brutalement. Là où tout le monde a déjà créé N bases de données (SQL etc.) et pense assez bien connaître le principe, les gens ayant un minimum d'expérience pour concevoir un annuaire LDAP sont assez rares. Et les concepts même ne sont habituellement pas maitrisés (ce n'est pas de leur faute, hein ?, c'est juste qu'ils n'ont pas eu l'occasion de savoir). D'où la transposition des principes des SGBD[R] qui conduisent fatalement à de mauvaises expériences.