[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sdx-developers] Plusieurs bases
From: |
Pierrick Brihaye |
Subject: |
Re: [sdx-developers] Plusieurs bases |
Date: |
Wed, 19 Jun 2002 16:51:54 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 |
Re,
Martin Sévigny wrote:
Imaginons une application d'un service public d'ampleur nationale ;-)
qui dispose de... disons 22 documentBase.
Ici, je comprends que les 22 bases contiennent des documents différents.
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 :-)
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.
*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).
J'oublie le terme "bases locales" pour considérer que tu veux dire l'une
ou l'autre des 22 bases propres à l'application dont on parle.
Cela permet, par exemple, d'offrir une formulaire de recherche avec des
cases à cocher pour laisser le choix à l'utilisateur. Et aussi de faire
des choses plus complexes.
On est d'accord.
Ou bien je ne comprends pas, ou bien tu ménages des choses ;-)
Qui sait ;-)) ?
> Pour le multilinguisme, explique-moi ce que tu veux atteindre comme
> objectif, parce que je ne te suis pas là-dessus (ni sur un précédente
> message d'ailleurs, mais j'avais oublié).
Tu as une collection de documents que tu indexes en 22 bases
différentes, mais chaque document est indexé (et stocké) une seule fois,
non?
Oui... mais ça, c'est l'approche "basique". Je m'explique :
J'ai des dossiers en français que je sais indexer suite à la remise d'un
cahier des charges par un public (francophone) donné, les chercheurs
d'Inventaire pour les nommer.
Ceux-ci ont une culture d'indexation très fine, pas forcément toujours
pertinente selon moi, mais là n'est pas le problème. Pour prendre un
exemple simple, SCLE n'est pas aussi intuitif qu'il y paraît : il
mentionne un siècle de campagne de construction *principale*. Si on veut
un siècle de datation *secondaire*, il faut utiliser SCLD. Passons sur
l'opposition entre les deux qui, elle, est encore plus tordue...
Arrive un nouveau public, francophone ou non, avec sa demande
particulière dont le déploiement sous SDX serait confié à une SSII pour
qui on dira que l'index SCLED = SCLE | SCLD de l'indexation préexistante.
Là, j'ai plusieurs approches :
- on patche la documentbase d'origine en créant un index supplémentaire
nommé SCLED : gros conflits en perspective avec le premier concepteur :
il faudra qu'il partage sa feuille d'indexation, qu'il ouvre les
ressources, etc. A supposer que cela se fasse sans heurts, il faut bien
sûr relancer une indexation. C'est là que les 22 bases feraient ça mieux
qu'une seule.
- 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.
- 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"...
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).
C'est sûrement prévu, mais ce n'est peut-être pas suffisant. Explique ce
que tu veux dire par indexation en N langues d'un même document.
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".
C'est un problème différent. Si tu penses à une super-application qui
fait des recherches sur des bases de documents hébergées sur un autre
framework, alors il faudra utiliser des outils de type Web services (ou
API URL de SDX) qui seront ajoutés pour faire ce genre de multibase.
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...
Mais pour des raisons de performance (en recherche), moi je préconiserai
en général ce scénario :
- indexation dans une application (à une ou plusieurs bases, peu
importe) "nationale" des contenus locaux, mise à jour périodique de
cette indexation
- affichage des documents (une fois cherchés dans la base nationale)
directement depuis les applications locales ou depuis leur URL d'origine
De cette façon, les documents sont à jour, mais pas nécessairement les
index. Comme Google quoi.
J'ai bien compris et ce schéma me semble tout à fait fonctionnel. Mais
ça fait, comme dit plus haut, une charge supplémentaire sur le design de
l'application dont je me demande s'il elle ne sera pas trop forte.
Et avec une utilisation judicieuse des URLRepository, les documents ne
sont pas copiés...
On est d'accord.
Et c'est rapide : parce que faire une recherche dans 22 bases dispersées
dans autant de DRAC, Lucene ne le fera pas en 30ms et il ne faut pas lui
en vouloir ;-)
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.
A+
--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
- Re: [sdx-developers] RE : Utilisation des tables associees, (continued)
- Re: [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/18
- [sdx-developers] RE : Utilisation des tables associees, Martin Sévigny, 2002/06/18
- Re: [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/18
- [sdx-developers] RE : Utilisation des tables associees, Martin Sévigny, 2002/06/18
- Re: [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/18
- [sdx-developers] RE : Utilisation des tables associees, Martin Sévigny, 2002/06/18
- Re: [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/19
- RE : [sdx-developers] RE : Utilisation des tables associees, Martin Sévigny, 2002/06/19
- Re: RE : [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/19
- [sdx-developers] Plusieurs bases, Martin Sévigny, 2002/06/19
- Re: [sdx-developers] Plusieurs bases,
Pierrick Brihaye <=
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/19
- Re: [sdx-developers] RE : Plusieurs bases, Pierrick Brihaye, 2002/06/19
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/20
- Re: [sdx-developers] RE : Plusieurs bases, Pierrick Brihaye, 2002/06/20
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/20
- Re: [sdx-developers] RE : Plusieurs bases, Pierrick Brihaye, 2002/06/20