Re: [sdx-developers] RE : SDX 2 : implantation des entrepots de documents

[Pierrick Brihaye]

Re,

Martin Sévigny wrote:

> L'objet DocumentBase dont je parle (que ce soit une interface ou une
> classe pour l'instant ça ne me chicote pas beaucoup) représente ce
> concept de base de documents.


OK.


> Moi aussi je pense. Je me rappelais de tes commentaires à ce sujet, et
> j'ai hésité un peu, mais finalement j'ai trouvé que ça m'était plus
> naturel de le faire en entrepôts. Les documents, je voulais les garder
> indépendants de la notion de stockage. Mais bon, je crois que les deux
> approches se défendent.


Si j'ai dit ça, c'est que ça permet d'avoir un niveau d'abstraction plus 
grand et, par exemple, de sérialiser/désérialiser au niveau des 
documents qui resteraient ainsi l'une des grandes unités "atomiques" de 
SDX. Ceci permettrait par exemple de proposer un jeu d'API pour des 
outils de production ;-) qui devraient tout de même respecter 
l'interface ad hoc de SDX et d'ignorer superbement toute 
l'infrastructure sous jacente.

> On peut faire cela, mais je ne vois pas en quoi c'est plus réutilisable.

Ca permettrait, le cas échéant, de changer de type d'entrepôt.


> En fait, je crois qu'elle va disparaître. Ca c'est du nettoyage!


Milosevic va désormais sévir dans SDX ? :-))

> Si on oublie l'entrepôt discuté auparavent, on a
> ici des bases (qui deviendront des applications), des utilisateurs et
> des groupes, le reste c'est des relations entre tout cela.


Je te suis complètement là-dessus. Pour prendre l'exemple d'un SGDB, ses 
métadonnées, ses privilèges, il les met... dans des tables. Donc SDX 
pourrait très bien les mettre dans des bases.


> Je constate que tu proposes des choses qui ont tendance à augmenter
> l'importance du SGBD, R ou XML.


Je pense essentiellement à la gestion des résultats. Voici comme je vois 
les choses :

- Récupération du résultat Lucene
- Mapping sur un SGDB (puis libération rapide de l'objet fourni par 
Lucene qui peut être très lourd)
- A partir de là le SGDB gère les résultats, en particulier le *tri* et 
ne renvoie au client que ce qu'il a demandé.

Le SGDB propose *nativement* (au moins, on l'espère) une gestion 
optimale de la mémoire, du caching, voire un déport sur un autre 
processeur ou une autre machine... C'est là que l'on peut trouver de la 
performance. A moins d'avoir à gérer un code très lourd de threading et 
de ramasse-miettes, *je* ne vois pas comment on pourrait faire 
autrement, au moins pour une version 2.

Attention cependant, je ne dis pas que c'est trivial. La forme des 
résultats n'étant pas connu par avance, cela risque d'impliquer 
plusieurs tables et, avec des outils comme MySQL, l'intégrité 
référentielle doit être codée en dur...

PS : nos amis flamands on fait une demande de "tech support". je n'ai 
pas su quoi répondre...

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden