Re: RE : [sdx-developers] HSQLDatabase

[Pierrick Brihaye]

Salut,

Martin Sevigny a écrit:

> Plus précisément...?

V. le courrier qui a suivi :-)

> Tu sais, on peut tout refaire le nommage SDX (jeux
> d'index, lookups, etc.), mais en même temps, des noms, ce sont des noms,
> et il s'en trouvera d'autres pour se plaindre (moi le premier!).

On est d'accord. C'est sans importance à vrai dire... Enfin, pour le moment.

> Database était une abstration pour la gestion de données champ=valeur.
> Caché dans "utils" pour éviter de laisser penser que SDX est un outil de
> base de données.

J'avais bien compris. Et j'étais assez d'accord avec cette approche ; je 
le suis un peu moins maintenant et ce, pour une autre raison : je viens 
d'avoir la REVELATION :-)))

> > - une interface relationnelle (avec 2 tables) qui saurait
> > tirer parti des SGDB sous-jacents.
>
> Deux tables? Tu peux expliquer?

Table 1 : ID
Table 2 : ID_table_1/nom-propriété/valeur_propriété

... avec une destruction en cascade.

On peut faire avec 3 tables :
Table 1 : ID
Table 2 : ID_table_1/ID/nom-propriété
Table 3 : ID_table_2/valeur_propriété

Note : dans la table 2, on peut considérer le couple 
ID_table_1/nom-propriété comme une ID pour cette table. On aurait encore 
des destructions en cascade.

> Si une entité a 4 propriétés
> potentiellement multivaluées, nous parlons bien de 9 tables, non?

On peut aussi :-) Sérieusement, avec une table, ça devrait aussi très 
bien marcher !

Mais bon, ça n'a que peu d'importance : ça serait juste pour (un peu) 
mieux coller à l'architecture SGDBR dont je ne pense, à vrai dire, pas 
toujours le plus grand bien :-)

> L'interface Database de SDX a pour objectif (peut-être mauvais) de faire
> abstraction des structures de données (propriétés des entités) qu'elle
> gère. Pour changer cela, il faudrait faire des modèles spécifiques pour
> les différents lookups dont on a besoin. Et faire évoluer les modèles
> avec les évolutions de SDX... Pas impossible mais travail de réflexion
> préliminaire à faire.

Je sais :-) Voici l'idée qui m'avais traversé la tête (pour les archives) :

En gros, on aurait au coeur de SDX une espèce de backbone où 
circuleraient des flux XML (SAX) émis par les différents composants. 
Réciproquement, les composants seraient capables de repérer les données 
qui leur seraient destinées (lecture de l'élément racine par exemple). 
Ainsi, si on a dans le backbone un flux du genre :

<sdx:lookup>
  <sdx:docid>xxxx<./sdx:docid>
  <sdx:url>une url</sdx:url>
</sdx:lookup>

Un LuceneLookup serait capable de mapper ça sur du Lucene, un JDBCLookup 
 sur un SGDB, un XMLDBLookup sur du XML:DB...

Est-ce qu'on a une architecture open source qui travaillerait comme ça ? 
A vrai dire, je m'étonne que Cocoon n'ait pas prévu nativement un 
mécanisme de ce type... Ca viendra peut-être ?

Trop tard pour SDX 2 de toutes façons... c'était pour les archives :-)

> > J'y serais assez favorable... pour les raisons que tu as
> > indiquées. Mais bon, il faut que ça soit robuste.
>
> Oui, donc il faut tester...

Je vais le faire... Au vu du code, j'ai confiance.

> > V. plus haut. Eventuellement, pour SDX 3, on pourrait ajouter
> > une troisième interface (s'ajoutant aux 2 mentionnées plus 
> > haut) qui serait native XML et qui pourrait s'interfacer avec 
> > une XML:DB. Dans ces conditions, je me demande si le couple 
> > Entity/Property n'aurait pas à gagner à être modélisé en XML natif...
>
>
> Sauf erreur:
>
> <entity id="...">
>   <property name="...">
>     <value content=""/>
>     <value content=""/>
>     <value content=""/>
>   </property>
>   <property>
>     ...
>   </property>
>   ...
> </entity>

Par exemple...

> J'ai mis les contenus en attributs pour bien montrer que c'est du
> PCDATA, pas du mixed content.

Bien compris.

A+

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