Re: [sdx-developers] Une base de documents sans entrepot?

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit :

> > > Ah, je vois ce que tu veux dire dire. Pour moi ce n'est pas une 
> > > dépendance, c'est un "scope", il n'est pas visible pour les autres...

> > Joli :-) Bon, ben... dans ce cas, je préférerais le scope inverse :-)
>
> Scope inverse?

Les repos qui verraient les bases de documents (aka index).

> > ... et Candide de poser 2 questions :
> >
> > 1) A quoi ça sert alors ?
>
> ;-)
>
> Deux cas de figure:

... auxquels je souscris :-)

> 1) On a une application avec plus d'un million de documents indexés dans 
> SDX, mais on n'a jamais besoin de retourner dans l'entrepôt, de revoir 
> les documents, car toute l'info est dans des champs SDX. Inutile de dire 
> que les documents sont très simples...

2.5 D tout de même : OK.

> 2) On aura une autre application où cette fois on a besoin de retrouver 
> les documents, mais qui sont en fait des enregistrements dans une base 
> de données relationnelle.

Oui : ça reviens au polymorphisme documentaire que je décrivais. On est 
d'accord.

> Il y en aurau autour de 8 millions dès le
> départ. Ici, seul l'ID est nécessaire pour construire le document

C'est ce postulat auquel je n'adhère pas. ID = *un* champ (Lucene), 
aya,t une valeur unique dans le scope qui plus est. Moi, je peux avoir 
besoin de N champs Lucene, éventuellement multivalués, pour construire 
de quoi retrouver mon document (idéalement, via un reader Cocoon).

Mais, dans les grandes lignes... on est d'accord !

> et on 
> ne veut pas stocker du XML car c'est inutile. Donc pas besoin de passer 
> par un entrepôt.

D'accord aussi.

> Dans les deux cas, le plus simple (actuellement) est de prendre un 
> entrepôt URL et de ne pas s'en servir. Mais ça fait tout de même un 
> lookup de très gros pour rien, avec tout ce que ça entraîne...

Itou.

> Intéressant, mais même pour cela pourquoi ne pas utiliser un entrepôt 
> spécifique? Il reçoit un ID et à lui de reconstituer le XML nécessaire 
> pour SDX...?

Bien sûr ! Mais, v. plus haut : une ID a des contraintes "ontologiques 
(unicité dans l'unicité - putain, ça fait smart -) que je ne peux/veux 
peut-être pas fournir.

Un document unique peut *aussi* se définir par une combinatoire de 
valeurs dans une combinatoire de champs.

Exemple :

<document id="the_simpsons">
  <parent>Homer</parent>
  <parent>Marge</parent>
  <enfant>Bart</enfant>
  <enfant>Lisa</enfant>
  <enfant>Maggie</enfant>
</document>

qui est différent du "plus simple" :

<document id="a_not_so_well_known_family">
  <parent>Homer</parent>
  <parent>Marge</parent>
  <enfant>Bart</enfant>
</document>

Donc... je reviens sur ma question : ne serait-il pas opportun de 
définir dans SDX une interface à même de choper des champs et de 
construire une URL vers le document ad hoc ? A charge, bien sûr, pour le 
développeur d'appli d'implémenter cette interface et de gérer les 
éventuels conflits d'unicité...

Ai-je été clair ?

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78