sdx-developers
[Top][All Lists]
Advanced

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

[sdx-developers] Re: [sdx-users] Utilisation des tables associees


From: Pierrick Brihaye
Subject: [sdx-developers] Re: [sdx-users] Utilisation des tables associees
Date: Tue, 18 Jun 2002 09:34:10 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3

Salut,

Je réponds sur la liste développeurs car ma réponse est fortement liée à des problématiques déjà discutés :-)

Depuis les tout début de SDX 1, il est possible de définir des tables
associées (aux documents XML indexés) à l'aide de la construction
suivante (par exemple) dans le fichier de configuration (db_info.xml) :

<sdx:tableList>
        <sdx:table name="va">
                <sdx:column name="source" datatype="VARCHAR(200)"
notnull="1" docid="1"/>
                <sdx:column name="cible" datatype="VARCHAR(200)"
notnull="1" docid="1"/>
                <sdx:constraint name="pkey" type="PRIMARY KEY">
                        <sdx:column name="source"/>
                        <sdx:column name="cible"/>
                </sdx:constraint>
        </sdx:table>
</sdx:tableList>

J'aimerais avoir une idée des applications qui ont besoin de cette
fonctionnalité, et pourquoi. Merci de nous renseigner à ce sujet, cela
pourrait avoir un impact sur le développement de SDX 2.


Là encore, un cas pratique : ma cartographie ;-))

Il existe quelques moteurs cartographiques sur bases SQL : Oracle-Spatial, PostGIS (sur Postgres), AlovMap (sur différents moteurs) et, surtout, une spécification de l'Open GIS Consortium : Simple Features for SQL dont le succès va grandissant (PostGIS en est une déclinaison). Il aura fallu attendre des années pour avoir des schémas assez génériques dans ce domaine...

Parmi les différents choix d'implémentation, j'aurais aimé conserver la possibilité de mapper sur du SQL. Un truc du genre : SRID (référentiel), WKT (forme géométrique en "well known text"), id_sdx (pour faire le lien avec l'indexation texte) et, pour éventuellement gagner de la performance, quelques champs "brief" de l'indexation texte (dont le formatage n'est pas forcément évident d'ailleurs...).

Ce serait la solution la plus simple pour moi (il faut entendre par là, celle qui nécessite le moins de codage sur les outils dont je dispose).

C'est dans ce sens où j'avais compris la DocumentBase comme étant indépendante des moteurs d'indexation car je voyais, lors du versement d'un document, une double indexation : le texte sous Lucene, le géométrique sous un moteur SQL quelconque, avec, dans les 2 cas (surtout le 2ème en fait), la possibilité de retoucher le XML de façon à pouvoir générer les coordonnées de la "bounding box" (on peut aussi imaginer de la générer grâce un mécanisme de trigger ON INSERT/ON UPDATE).

Se pose néanmoins le problème de l'accès aux tables : d'après le code que tu donnes, il semble que ce soit SDX qui gère la création de la table. Dans mon cas, je préfèrerais la déléguer au système SIG parce que la structure sous-jacente est très fortement codifiée. SDX n'aurait qu'à vérifier que les métadonnées de ce SIG correspondent bien aux métadonnées fournies ou, mieux, que les contenus résultant de l'indexation "tabulaire" sont conformes aux métadonnées sous-jacentes.

Pour terminer sur l'opportunité de cette indexation, Frédéric avait évoqué (message du 11/06, 17h33) une base de "produits/clients", mais bon, il avait aussi parlé de "mauvaises habitudes" :-)

A+

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




reply via email to

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