Ceci n'est pas un topikatroll.
 
Je m'interroge sur l'intérêt des naming and directory services, face à la traditionnelle base de données relationnelle.
 
LDAP par exemple : ça sert à faire persister de l'info, ça va vite en lecture, pas en écriture. Pour l'instant je ne vois pas la foutue différence qui en fait un concept à part, comparé à une RDB.

Up !

tiens, je l'avais pas vu ce topic. J'ai un ami qui a fait un mémoire sur les LDAP, je vais voir si j'y trouve un élément de réponse.

Pour faire plus simple, j'ai été interroger le mec à la source. Voila le copier/coller de la discussion:

Merci pour ce ICQ snippet !
Il y a un truc que je me demande, ayant lu l'explication de Whyjack, c'est le stockage au format textuel. ça veut dire quoi, texte au sens de quel encodage. Et j'ai lu que l'on pouvait sérialiser des objets Java dans des annuaires LDAP... Quid du format texte, donc ?

d'apres ce qu'il me semble tu peux avoir des types dans un ldap
 
au fait l'abbreviation NDS tu la sors d'ou? jms vu ça moi

je pense que quand il parle de format textuel, il parle d'un format non compressé ou crypté.

jms c'est Java Messaging Service (je crois)

 
Dans un bouquin sur Java côté serveur. Un passage sur JNDI.

j'arrive pas à retrouver l'accronyme qui me semble etre le "bon"..

Le problème c'est que NDS, c'est le Novell Directory Server. Donc mon acronyme est pourri. Reflexion faite, c'est dans le tutorial de Sun sur JNDI, ils parlent de Naming and Directory Servers, j'en ai fait l'acronyme NDS, benoitement (benou-staïle quoi )

 
JNDI

euh ben oui en fait
c pas vraiment que je cherchais mais c'est qd meme une bonne réponse

Oui, mais non.

 
ce n'est pas à toi que je parle. Je sais très bien que ce n'est pas le terme adéquat (c'est le terme dans le monde Java).
 
Je répondais à greg en étant presque sur que c'était à ce terme là qu'il pensait.

Sinon, qu'est ce qui fait qu'une entreprise ayant une license Oracle ou DB2 ou autre, achètera une license Domino ou autre pour se mettre un annuaire LDAP. Pourquoi ne créerait-elle pas plutôt une base dans son RDBMS et intégrerait celle-ci dans son SI ?

l'accessibilité à l'information n'est pas la même (de même que la standardisation des domaines)
 
J'ai l'impression que tu vois LDAP comme un machin qui permet de persister des données en base mais c'est faux. Derrière ce stockage d'info (des users par exemple) tu as tout un tas d'interfaces qui te sont offertes pour y accéder à l'info.
 
Alors ajouter une base dans ton SGBD c'est bien beau mais après tu dois écrire la logique qui permet d'y accéder, de filtrer l'info, etc.
 
Je ne comprends pas vraiment ta question en fait

 
ah bin effectivement c'était pas qu'une impression.

 
vu les termes que tu utilises t'es un futur dirigeant toi, y a pas de doute

J'envisage sérieusement de monter ma boite dans une dizaine d'années, ouais.

Ben quoi, tu veux que je t'embauche ?

 
Certainement pas.
 
Blague à part, des remarques concernant ce que j'ai écris pour SGBD vs Naming directory?

Pas pour l'instant. J'avais pas vu, en fait.

Tu as des exemples ?

Ben dans mon bouquin, programmation Java côté Serveur, j'ai ça :
 

 
C'est là que je ne perçois plus la différence entre LDAP et une base de données. Pour exemple, IBM développe un annuaire LDAP appelé IBM Tivoli Directory Trucmuche, et dans le zip, tu trouves : DB2 et WebSphere.

tiens j'avais un truc à dire ici.
tout à l'heure. uppes le topic d'ici 1h ou 2 , que j'y repense.

J'y connais rien en LDAP, mais juste pour voir si j'ai bien suivi :
 
En gros LDAP n'est pas un système de stockage (persistance), c'est plus un protocol d'accès à l'info. En très gros, c'est plus proche d'un language comme SQL.
 
En fait rien n'interdit d'utiliser un SGBD pour gérer la persistance d'un LDAP. C'est juste la manière de lui causer qui change.

d'ailleurs c'est ce que font certains serveurs ldap

bon oui, ce que je voulais dire..
sous réserve hein, je me plante peut etre completement.
 
avec un ldap, tu n'es pas limité par un "datamodel" fixe, tu peux avoir des attributs "dynamiques". exemple:
 
j'ai un ldap/une db qui recense les employés de ma boite; attributs classiques style nom prénom adresse n° compte banquaire email telephone.
tout ça est tres bien.
en amont j'ai une petite appli qui me permet de faire des recherches sur ces champs.
 
bon, le "problème" intervient le jour ou je me dis que merde, il faudrait que je garde un trace du n° de badge d'accès au batiment de chacun.
* scenario de merde: j'ai une db. chiotte, je dois: mettre à jour mon script d'init-db dans la procedure d'install de mon appli; mettre à jour la db de prod (alter table...); mettre à jour mon appli elle meme pour qu'elle prenne le nouveau champ en compte.
* scenario pèpère: j'ai un ldap. je met mon appli a jour, et hop.
 
en effet, il existe un "champ" dans les ldap, notamment sur les "schema" de base style celui pour recenser les personnes, qui ne prend pas UNE valeur, mais une serie de paires clé-valeurs. et on peut simplement faire des requetes sur ce champ pour une clé donnée.
 
Désolé pour le manque de précision du vocabulaire, et, je le répète, cette info est à vérifier, mais je pense que je suis pas *trop* loin d'une vérité qui serait donc un bon avantage par rapport a un rdbms dans certains cas.

Un peut dans le style "base de registres" alors ?

je n'sais pas

Oui effectivement, LDAP supporte bien l'ajout de multiples attributs et surtout de multiples valeurs pour ces attributs.

le seul interet que je vois, c'est la standardisation pour l'acces aux données. utile pour l'intégration de progiciels & cie...

 
Le fait est que tu prends un exemple qui n'est pas du tout représentatif de ce que LDAP fournit comme fonctionnalité (désolé de ne pas avoir répondu à ton autre post j'ai oublié).
 
Avant de te casse la tête et de le comparer à une base de donnés () essaie peut etre de te baser sur un exemple vraiment représentatif de ldap.
 
Exemple1: un annuaire du personnel. Le personnel est classé en différents départements, chaque membre a des attributs bien spécifiques, des droits d'accès sur les machines de production, d'intégration, etc. Avec un login unique les accès d'un utilisation sont stockés à un seul endroit
 
Exemple2: l'utilisation en J2EE pour stocker les références vers proxy et autre session pools
 
Maintenant prends ces exemples, essaie de les traduire en des implémentation utilisant une BD (avec rien au dessus) et tu la verras la différence. J'ai vraiment l'impression que tu vois tout ca comme "j'ai un objet truchmuch avec telles et tellles propriétés et je stocke ca qqaprt".
 
Et l'accès à l'information?
 
En ce qui concerne Tivoli, est ce que tu sais ce que c'est au moins? Si après, dans leur implémentation propre à eux, ils mettent un DB2 derrière pour stocker les données c'est leur problème. C'est pas pour ca que tu dois confondre le concept global et l'implémentation.
 
On peut ouvrir un topic c'est quoi la différence entre un entity bean et une table d'une base de données si tu veux. C'est du même niveau.
 
(Et je ne suis pas un fan de LDAP hein au cas où certains se poseraient la question, c'est la comparaison avec une BD qui a l'air de durer dans le temps que je trouve dingue)

l'arbre à cerise est pas passé

Me voilà. Je suis venu, j'ai lu, et j'ai comprus.
 
1) L'accès à l'information. Je peux pas trop juger, je n'ai ni utilisé JNDI ni quelque autre API LDAP que ce soit (style Netscape, c'est celle qu'on a la boite). En revanche, je pense savoir ce que c'est que de vérifier si un user existe et à suffisamment de privilèges, avec une base de données. Je me dis que ça ne peut pas être beaucoup plus léger que ma petite requête SQL ; mais j'ai sans doute tort.
 
2) l'utilisation de J2EE... là, je ne peux vraiment rien dire. Je n'ai aucun point de comparaison.
 
Le truc qui m'effraie avec Tivoli, c'est ma vision PME. ça me parait lourd de faire gérer l'annuaire à une webapp. Alors que (c'est ma croyance du moment, hein, ne te fâche pas) une petite requête SQL et hop ! Bon si tu t'en sers pour stocker tes références vers proxy toussa, je dis plus rien.

mais t'as vraiment rien compris putain.
 

 
dans un domaine relativement simple et stable, probablement.
 
Que dans ton cas de PME à toi, une requête SQL soit plus simple que l'utilisation de LDAP ou autre c'est parfait, mais c'est pas une raison pour le comparer à une base de données.  
 
Est ce que tu réalises que ca n'a pas de sens? Enfin, je veux dire est ce que tu réalises en quoi tu généralise un concept à ton cas qui n'est pas représentatif?
 
C'est un peu comme le mec qui n'a pas besoin de plus qu'excel pour stocker ses données et qu'il ouvre un thread "c'est quoi la différence entre excel et mySQL"
 
Quand à l'utilisation de Tivoli en PME ... C'est bien ce que je disais, un futur dirigeant

Il se trouve que j'ai eu Qcslapd et OpenLDAP sous la main, et ni l'un ni l'autre ne me vont. Le premier causait des problèmes à l'application que nous développons, le second a commencé à montrer des signes de fatigue la semaine passée. Pour nos tests, et vu la situation financière de la boite, je cherche une autre implémentation de LDAP gratuite. C'est là que je suis tombé sur le serveur LDAP de Tivoli. Quand j'ai eu dézippé l'archive, je me suis demandé : "au fond, pourquoi on s'enquiquine avec LDAP". Ni plus ni moins.
 
Je n'ai pas cherché à généraliser. J'ai une expérience avec LDAP, qui ne m'a pas convaincu de l'utilité du truc par rapport à une base relationnelle. Bon, je demande. Pas la peine de le prendre comme ça... Tu te rends compte au moins, que tu t'irrites de la pauvreté intellectuelle des gens parce que tu as compris avant eux un concept informatique ? Avec moi tu n'as pas fini !