sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-developers] RE : Plusieurs bases


From: Martin Sévigny
Subject: [sdx-developers] RE : Plusieurs bases
Date: Wed, 19 Jun 2002 17:26:17 +0200

Salut,

Bon, je pensais que l'architecture était souple, mais c'était sans
compter les besoins de l'Inventaire!

> Mmmmh. C'est plus délicat à mon avis. J'ai bien compris que, 
> idéalement, 
>   il vaut mieux mettre N types de documents différents dans N bases, 
> possibilité dont je ne vais pas me priver d'ailleurs :-)

Je ne disais pas cela. Je pensais que tous tes documents étaient de même
structure, mais de provenance différente.

> Pour expliciter : les dossiers d'inventaire dans une base, la 
> documentation sur les opérations d'Inventaire (en Docbook si tant est 
> que je parvienne à en obtenir un jour !) dans une autre.

C'est que je ferais, à vue de nez.

> *Mais* dans une perspective de déploiement efficace, je 
> pressens qu'il 
> vaut mieux déployer 22 bases qu'une seule. Ma longue 
> expérience me fait 
> dire que c'est la meilleure façon de ne froisser personne et 
> de créer de 
> l'emploi :-) Sans compter le gain de performance : mieux vaut 
> indexer 40 
> Mo sur 22 serveurs que 880 Mo sur un seul... et récupérer 22 "petits" 
> lots de résultats qu'un "gros" tout seul (enfin... dans un 
> monde idéal 
> où tous la bande passante ne tend pas vers epsilon ; on en 
> reparle à la 
> fin de ce message).

Je te corrige : si tu parles de 22 serveurs, alors tu parles
nécessairement de 22 applications SDX, et même 22 frameworks. Pas de 22
bases au sein d'une même application.

> - on crée une application spécifique (avec bases spécifiques ayant le 
> fameux index SCLED... mais pas SCLE et SCLD) et, dans ce cas, 
> les deux 
> publics s'ignorent superbement : pas possible, étant donné la 
> fragmentation en applis différentes, d'envoyer une requête en 
> anglais, 
> en français, sur SCLE, sur SCLD ou sur SCLED... sans compter 
> le problème 
> de la mise en forme des résultats, différente d'une appli à une autre 
> probablement et potentiellement générateur de divergences. De but en 
> blanc, cette approche me paraît pire que la précédente.
> 
> Ces deux premières approches sont compatibles avec SDX tel qu'il est 
> dans le CVS.

Oui, mais une précision : l'interrogation multibase sur Lucene
fonctionne de façon transparente d'une application à l'autre. Tu pourras
faire une recherche sur 4 bases provenant de 3 applications par exemple.
La seule contrainte, c'est que tu connaisses les identifiants publics
des applications, et les identifiants des bases (si tu ne connais pas
ces derniers ce sera la base par défaut).

> - on mutualise autant que faire se peut, chacun restant 
> néanmoins dans 
> son rayon. Là, une base générique pourrait dispatcher la requête aux 
> différents index, à charge pour eux de répondre ou pas : "pas d'index 
> SCLED", "Sorry, I don't speak french"...

Une application générique peut aussi le faire. Pourquoi ton concept de
base générique serait plus intéressant ici?

> Mais bon, je suis d'accord avec toi que le design de 
> l'application peut 
> grandement masquer les architectures sous-jacentes... mais 
> cela aura un 
> prix (dans les deux sens du terme).

En fait, je réalise que utilises un critère qui a été ignoré jusqu'à
maintenant : le développement d'applications SDX par différentes
institutions (SRI, SSII) qui n'ont pas forcément les mêmes intérêts.
J'avais toujours imaginé qu'on pouvait considérer une application comme
étant sous une même "autorité morale".

> Sans aller jusqu'à une traduction simultanée des documents à 
> indexer, on 
> pourrait utiliser des dictionnaires pour traduire les index dont le 
> nombre de valeurs est plus ou moins clos : SCLE = "19e 
> siècle" vs SCLE 
> (multilinguisme "vrai") = "19e siècle/19th century" vs CENTURY 
> ("pseudo-mutilinguisme") = "19th century".

J'ai assez réfléchi à ce problème, et j'avoue que j'ai toujours pensé le
régler au moment de la requête. Mais peut-être qu'il y a des choses que
je ne vois pas.

> Pas forcément. Je pense plutôt à :
> 
> - *un* framework : bases du MCC
> -- *une* appli : Inventaire
> --- *des* bases : dossiers/documents (éventuellement en 22 
> exemplaires)
> ---- *des* repositories : XML CI, XML Docbook, images, fonds 
> de carte...

Hormis la question de l'autorité morale de l'application (et de tout ce
qu'il y a en-dessous), c'est le schéma SDX 2 que tu décris.

> Là, je ne peux qu'être d'accord mais ça pose le problème du 
> haut-débit 
> au MCC. Soyons optimistes : ça ne peut que s'arranger.

Bien sûr. Et tant mieux. Pour STRABON, par exemple, les frameworks
seront dans les pays méditerrannéens, alors ça s'arrangera peut-être
moins vite!

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]