🚀 go-pugleaf

Bonjour, il y a quelques mois, avec des coll�gues, nous avons eu la m�me
discussion qui pourrait se r�sumer � la question essentielle : En quoi XML
vaut-il mieux qu'une base de donn�es ? A cette question, la seule r�ponse �
peu pr�s convenable est : en rien !
En fait, d�s lors qu'on s'int�resse aux donn�es stock�es physiquement,
l'int�r�t essentiel de XML devient de fournir une interface banalis�e de
haut niveau. C'est-�-dire qu'un programme utilisant pour stocker des donn�es
un document XML peut tr�s bien, en fait, utiliser une base de don�nes vue
comme un document XML. C'est d'ailleurs ce qui pousse les gens � utiliser
XML dans ces cas : il suffit de sp�cifier l'API utilis�e, en g�n�ral le DOM,
et les d�veloppeurs peuvent alors travailler ind�pendament. Le sp�cialiste
base de donn�es �crit un driver supportant l'interface DOM et fonctionnant
comme il lui plait, ety les d�veloppeurs d'application �crivent leur
applciation en ne sauvant plus que gr�ce �cet API. Du coup tout le monde est
content : les don�nes utilisent un format banalis� pour circuler dans
l'application, et sont sauv�es dans une base correspondant � des
sp�cifications bien connues.

Nicolas Delsaux

Mathieu Baudier <mbaudier@free.fr> a �crit dans le message :
8u14vh$2p0i$1@news6.isdnet.net...
> Bonjour,
>
>  je suis en train de me mettre � XML (surtout cr�ation de sites /
> programmation Java)
>
> Je vois bien l'utilit� de XML pour les transferts de donn�es et pour les
> fichiers de config de logiciels, en revanche je ne vois pas tr�s bien
> comment l'utiliser efficacement en stockage:
>
> Comment �viter la redondance avec les bases de donn�es?
> Quand faut-il stocker sous forme de bases, quand sous forme de XML ?
>
> Merci d'avance
>
> Mathieu
>
>

"Mathieu Baudier" <mbaudier@free.fr> writes:

> Je vois bien l'utilit� de XML pour les transferts de donn�es et pour les
> fichiers de config de logiciels, en revanche je ne vois pas tr�s bien
> comment l'utiliser efficacement en stockage:

C'est effectivement une bonne question...

> Comment �viter la redondance avec les bases de donn�es?
> Quand faut-il stocker sous forme de bases, quand sous forme de XML ?

A mon avis, les criteres decisifs, ce sont la frequence et la portee des
mises a jour a faire. Si les modifications sont frequentes sur des
petites parcelles de donnees (par exemple un site marchand en ligne),
mieux vaut utiliser une base de donnees SQL. Par contre, si les
modifications sont massives et relativement rares, on peut opter pour
des fichiers XML (par exemple, si le contenu est essentiellement
textuel, du style documentation technique).

Dans les deux autres cas (modification de faible ampleur et rares
d'une part, modification massives et frequentes d'autre part), je ne
vois pas de clair avantage pour l'une ou l'autre des techniques (sauf
pour ce qui concerne le texte, eventuellement en plusieurs langues, ou
XML a clairement l'avantage).

Deux remarques cependant :

* certains outils, comme Cocoon, permettent d'utiliser une couche XML
  par-dessus une base de donnees SQL, ce qui fait pencher
  l'homogeneisation du cote de XML

* il existe des bases de donnees XML, mais je ne sais pas quelles sont
  leurs caracteristiques, par exemple en termes de gestion des
  transactions, ou en termes de granularite du verrouillage

J'ajouterais que les bases de donnees XML ont beaucoup a voir avec les
bases de donnees objet, qui n'ont pas detrone les bdd relationnelles.
Donc, les couches XML/SGBDR ont a mon avis de l'avenir...

Voila, mes 2 eurocentimes.

-- Alain.

Mathieu Baudier wrote:
> 
> Bonjour,
> 
>  je suis en train de me mettre � XML (surtout cr�ation de sites /
> programmation Java)
> 
> Je vois bien l'utilit� de XML pour les transferts de donn�es et pour les
> fichiers de config de logiciels, en revanche je ne vois pas tr�s bien
> comment l'utiliser efficacement en stockage:
> 
> Comment �viter la redondance avec les bases de donn�es?
> Quand faut-il stocker sous forme de bases, quand sous forme de XML ?
> 
> Merci d'avance


Le doc de r�f�rence pour un tour de la question est "XML and Databases",
de R. Bourret
 
  http://www.rpbourret.com/xml/XMLAndDatabases.htm


eeq�a
 -jmd

Le principal int�r�t d'une base de donn�es sur des fichiers plats est :

- la gestion des acc�s concurrents
- la gestion des liens relationnels
- un langage d'interrogation quasi universel et performan (SQL)

Je ne vois pas en quoi XML serait concurrent ?? XML est une mani�re comme
les autres de stocker les informations dans des fichiers textes, si ce n'est
que la structure peut �tre r�cup�r�e via des DTD dont la syntaxe est
normalis�e. Je me trompe en disant �a ?

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

On Tue, 7 Nov 2000 15:14:13 +0100, Pierre Goiffon 
<pgoiffon.invalid@webcity.fr> a �crit:
>Le principal int�r�t d'une base de donn�es sur des fichiers plats est :
>
>- la gestion des acc�s concurrents
>- la gestion des liens relationnels
>- un langage d'interrogation quasi universel et performan (SQL)

Pour moi,le principale inconv�nient  d'un sgbd relationnel, c'est que l'on
stocke des lignes. Pour faire du multi crit�re (enfin, du crit�re
multi-valu�), il faut passer parune table de couple, ou un objet.
Quand on a un arbre, c'est bcp plus agr�able.

>
>Je ne vois pas en quoi XML serait concurrent ?? XML est une mani�re comme
>les autres de stocker les informations dans des fichiers textes, si ce n'est
>que la structure peut �tre r�cup�r�e via des DTD dont la syntaxe est
>normalis�e. Je me trompe en disant �a ?
>

Nonon, mais l'aspect manipulation de ces donn�es me parait important aussi.
XML permet de rechercher, de reorganiser, de mettre a jour ... etc.
C'est un peu ce que permettent les SGBD. Reste � raison garder, et utiliser
un outil dans le domaine o� il est adapt�.
Le probl�me qui me tracasse en ce moment, c'est g�rer les gros fichiers. La
solution s'appelle-t-elle SAX ?

J'en profite aussi pour  demander si quelqu'un a pu tester le module XML 
d'oracle, qui permettrait (conditionnel) de ramener des infos sorties d'une 
base de
donnees, sous format XML ( bof facile ) mais aussi de rassembler a travers
les cl�s �trang�res les infos associ�es.

-- 
Damien
Whistler's Law:
        You never know who is right, but you always know who is in charge.

M�me reflexion chez nous :-)

Conclusion : la BD est inutile.... :-) ca c'etait juste pour celui qui a dit
exactement l'inverse.

En fait la conclusion de nos r�flexions est : on utilise la BD uniquement
pour des informations dynamique sur un documents (du genre la moyenne
affecter � un document, le nombre de personne l'ayant consult�...), le reste
on g�re en XML.

Mais cela impose une contrainte forte : acc�der au info des documents
rapidement.

Pour cela on utilise un moteur de recherche (Fulcrum, Verity, Excalibur ou
autre) ou ..... un BD type repository XML (Poet, Documentum, Oracle iFS...)

Comme quoi les deux sont intimement li�s.

to be continued

> Conclusion : la BD est inutile.... :-)

Ben je ne comprend vraiment pas : l� nous parlons que d'une infime partie du
champs d'application des BDD... Non ? J'opposerai plut�t les fichiers plats
traditionnels � XML ! (souvent les BDD sont utilis�es alors que de simples
fichiers textes suffiraient)

Euh... vous pouvez m'expliquez ce que je ne vois pas ?

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

In article <8uem7t$ebr$1@reader1.imaginet.fr>, "Pierre Goiffon"
<pgoiffon.invalid@webcity.fr> wrote:

>> Conclusion : la BD est inutile.... :-)
> 
> Ben je ne comprend vraiment pas : l� nous parlons que d'une infime
> partie du champs d'application des BDD... Non ?

Je dirai plutot qu'on parle d'une infime partie du champ d'application
d'XML.

On peut tr�s bien utiliser XML comme format de stockage de BdD (en
d'autres termes, simplistes donc pas forc�ment tr�s juste mais ca donne
une id�e, XML *EST* une BdD)

> J'opposerai plut�t les fichiers plats traditionnels � XML !

XML n'est un "fichier", c'est une fa�on de s�rialiser un DOM, ici on
parle bien plus de DOM que d'XML.

En sch�matisant � l'extr�me et en ne consid�rant qu'une partie du
potentiel d'XML, on peut faire les analogies suivantes :
 - XML est le format de stockage et d'�change (au lieu d'utiliser
formats de fichiers et objets propri�taires)
 - XPath correspond � SQL, avec l'adjonction de la notion
d'arborescence.
 - le SGBD est le programme g�rant le parsing d'XML (vers un DOM) et 
l'�valuation d'expressions XPath, le r�sultat est retourn� soit sous
forme d'objets (node-sets, etc.) soit s�rialis� en XML (du texte donc,
qu'un parser/processor pourra retravailler si besoin, avec son
impl�mentation propre).

Mais je ne vois s�rement pas toutes les possibilit�s d'XML dans ce seul
champ d'application...

Tom.

Nous avons fait des tests avec du "s�rialis� XML" comme dirait Tom mais en
utilisant un moteur d'indexation externe (d�riv� d'un "robot" de recherche
en cours de design).
Le r�sultat est impressionnant, sur un m�me PC nous sommes � ma grande
surprise plus rapides en XPATH qu'en SQL (sur les bases relationnelles A...s
et O...e) avec l'int�ret de l'extraction de fragments en plus. Tests faits
sur une base de de 4 500 000 enregistrements comportant en moyenne une
vingtaine d'index. (On en peut pas en arborescence d�finir un nombre fixe
d'index comme dans une table relationnelle).
Je confirme donc que la solution du moteur de recherche WEB (modifi� certes)
associ� � XML est tout � fait efficace, y compris en transactionnel. On en
reparle dans deux mois?

Jean-Philippe BRUNET

"Jean-Philippe BRUNET" <jean-philippe.brunet@libertysurf.fr> writes:

> Nous avons fait des tests avec du "s�rialis� XML" comme dirait Tom mais en
> utilisant un moteur d'indexation externe (d�riv� d'un "robot" de recherche
> en cours de design).
> Le r�sultat est impressionnant, sur un m�me PC nous sommes � ma grande
> surprise plus rapides en XPATH qu'en SQL (sur les bases relationnelles A...s
> et O...e) avec l'int�ret de l'extraction de fragments en plus. Tests faits
> sur une base de de 4 500 000 enregistrements comportant en moyenne une
> vingtaine d'index. (On en peut pas en arborescence d�finir un nombre fixe
> d'index comme dans une table relationnelle).

Tres bien, mais quid de la mise a jour des donnees ? De la gestion des
acces concurrents ? De la verification des contraintes d'integrite ?

(Toutes choses qui font une base de donnees, et qui imposent des
contraintes sur le stockage et l'acces, donc il n'est pas, a priori,
etonnant qu'elles aient un impact en termes de performance.)

Vous avez une solution pour ca ?

> Je confirme donc que la solution du moteur de recherche WEB (modifi� certes)
> associ� � XML est tout � fait efficace, y compris en transactionnel. On en
> reparle dans deux mois?

La on ne peut qu'etre d'accord : XML est tres adapte pour faire de la
recherche dans des informations qui existent deja. Mais j'ai des
doutes sur ce que tu appelles le transactionnel. Je ne demande qu'a
etre contredit, cela dit....

-- Alain.

Jean-Philippe BRUNET wrote:
> 
> Nous avons fait des tests avec du "s�rialis� XML" comme dirait Tom mais en
> utilisant un moteur d'indexation externe (d�riv� d'un "robot" de recherche
> en cours de design).
> Le r�sultat est impressionnant, sur un m�me PC nous sommes � ma grande
> surprise plus rapides en XPATH qu'en SQL (sur les bases relationnelles A...s
> et O...e) avec l'int�ret de l'extraction de fragments en plus. Tests faits
> sur une base de de 4 500 000 enregistrements comportant en moyenne une
> vingtaine d'index. (On en peut pas en arborescence d�finir un nombre fixe
> d'index comme dans une table relationnelle).
> Je confirme donc que la solution du moteur de recherche WEB (modifi� certes)
> associ� � XML est tout � fait efficace, y compris en transactionnel. On en
> reparle dans deux mois?

 Quid des perfs en insertion ? Du v�rouillage ? De la s�curit� en
exploitation
(sauvegarde, redo logs,...)
 Peut on faire en XPath tout ce que l'on peut faire en SQL ? La r�ponse
est
clairement non, et les langages de requ�tes XML (comme Quilt par
exemple) tendent
de plus en plus vers des modeles hybrides pour permettre la mise � jour
des
donn�es.
 N�ammoins cette solution (utiliser un d�riv� d'un moteur de recherche)
est
sans doute int�ressante pour une application en consultation seule.

	Fabrice

Salut,
te serai-t-il possible de d�tailler ton test sans rentrer dans les aprties
confidentielles de cette application ?
Je souhaiterais en effet int�grer l'utilisation d'XML en tant qu'outil de
stockage, mais je ne dispose pas d'arguments suffisants pour convaincre
notre responsable bases de donn�es.

Merci

Nicolas Delsaux

Jean-Philippe BRUNET <jean-philippe.brunet@libertysurf.fr> a �crit dans le
message : 8uhjnq$1vl5$1@news5.isdnet.net...
> Nous avons fait des tests avec du "s�rialis� XML" comme dirait Tom mais en
> utilisant un moteur d'indexation externe (d�riv� d'un "robot" de recherche
> en cours de design).
> Le r�sultat est impressionnant, sur un m�me PC nous sommes � ma grande
> surprise plus rapides en XPATH qu'en SQL (sur les bases relationnelles
A...s
> et O...e) avec l'int�ret de l'extraction de fragments en plus. Tests faits
> sur une base de de 4 500 000 enregistrements comportant en moyenne une
> vingtaine d'index. (On en peut pas en arborescence d�finir un nombre fixe
> d'index comme dans une table relationnelle).
> Je confirme donc que la solution du moteur de recherche WEB (modifi�
certes)
> associ� � XML est tout � fait efficace, y compris en transactionnel. On en
> reparle dans deux mois?
>
> Jean-Philippe BRUNET
>
>
>
>

J'ai effectivement tester l'api xsu d'Oracle qui permet de generer du xml a
partir s'un bd Oracle ou d'en inserer.
En fait, pour une bd objet-relationnel, avec des types objet utilisateur, cela
marche tr�s bien , il te g�n�re un
document xml hirarchique sur plusieurs niveau, mais en ce qui concerne une base
de donn�e completement relationelle, il genere un fichier xml plats, meme si l'on
fait une selection entre deux table reli� par clef etranger.
Est ce que quelqu'un aurait trouv� une solution � ce probl�me, ou existe t'il une
autre api sur le march� qui est capable de generer une fichier xml hierarchique a
partir d'une bd relationnelle ??
Merci d'avance

Damien Salvador wrote:

>
>
> J'en profite aussi pour  demander si quelqu'un a pu tester le module XML
> d'oracle, qui permettrait (conditionnel) de ramener des infos sorties d'une
> base de
> donnees, sous format XML ( bof facile ) mais aussi de rassembler a travers
> les cl�s �trang�res les infos associ�es.
>
>

Euh, je ne connais pas xsu. J'avais r�cup�r� des infos sur PLSXML qui
contient des packages : DBXML, DBDOM et DBXSL.

J'ai trouv� �a � : http://technet.oracle.com/tech/xml/info/plsxml/details.htm

il faut faire un "DBXML.Query" avec l'option "includeDetails" sur Y , ce
qui, je cite :"will 'follow' foreign key constraints to find associated
information for the main table in your query. By default, it will not return
detail information."

Je n'ai malheureusement pas encore eu le temps de m'y int�resser, mais je 
serai tr�s int�ress� si quelqu'un le peut :-)

On Thu, 16 Nov 2000 10:27:21 GMT, Val�rie S�guy 
<vseguy@free.fr> a �crit:
>J'ai effectivement tester l'api xsu d'Oracle qui permet de generer du xml a
>partir s'un bd Oracle ou d'en inserer.
>En fait, pour une bd objet-relationnel, avec des types objet utilisateur, cela
>marche tr�s bien , il te g�n�re un
>document xml hirarchique sur plusieurs niveau, mais en ce qui concerne une base
>de donn�e completement relationelle, il genere un fichier xml plats, meme si l'on
>fait une selection entre deux table reli� par clef etranger.
>Est ce que quelqu'un aurait trouv� une solution � ce probl�me, ou existe t'il une
>autre api sur le march� qui est capable de generer une fichier xml hierarchique a
>partir d'une bd relationnelle ??
>Merci d'avance

-- 
Damien
Whistler's Law:
        You never know who is right, but you always know who is in charge.

"Tom." <ptittom@free.fr> a �crit dans le message news:
576fu8.l32.ln@ptittom.free.fr...
> Je dirai plutot qu'on parle d'une infime partie du champ d'application
> d'XML.

:)
Oui c'est s�r c'est plus dans ce sens que j'aurais du formuler, mais
connaissant tr�s peu XML... :)

> (en d'autres termes, simplistes donc pas forc�ment tr�s juste mais
> ca donne une id�e, XML *EST* une BdD)

En quoi XML peut il �tre compar� � une BDD ? Un fichier CSV avec des outils
donne la m�me chose non ? La diff�rence pour moi, n�ophyte, c'est qu'avec
XML on dispose d'un grand nombre d'outils pour passer le contenu sous des
tonnes de formats...

La BDD est pour moi indispensable, le XML est une �tape pour repartir vers
un autre format ou �changer les donn�es avec un partenaire...

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

Une recherche dans un fichier texte est nettement plus rapide qu'une
interrogation BDD, je ne vois pas ce que XML y change ?? (vrai question de
n�ophyte)

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

"Alain Ketterlin" <alain@dpt-info.u-strasbg.fr> a �crit dans le message
news: wyvgtse36c.fsf@polya.u-strasbg.fr...
> La on ne peut qu'etre d'accord : XML est tres adapte pour faire de la
> recherche dans des informations qui existent deja. Mais j'ai des
> doutes sur ce que tu appelles le transactionnel. Je ne demande qu'a
> etre contredit, cela dit....

Haha, je ne suis pas le seul alors ? :)

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

In article <8v14jn$10a$1@reader1.imaginet.fr>, "Pierre Goiffon"
<pgoiffon.invalid@webcity.fr> wrote:

> "Alain Ketterlin" <alain@dpt-info.u-strasbg.fr> a �crit dans le
> message
> news: wyvgtse36c.fsf@polya.u-strasbg.fr...
>> La on ne peut qu'etre d'accord : XML est tres adapte pour faire de la
>> recherche dans des informations qui existent deja. Mais j'ai des
>> doutes sur ce que tu appelles le transactionnel. Je ne demande qu'a
>> etre contredit, cela dit....
> 
> Haha, je ne suis pas le seul alors ? :)

Je suis franchement pas sp�cialiste SGBD, j'y connais m�me pas grand
chose.
Mais je ne vois pas pourquoi les algos, etc. utilis�s par les SGBD
"normaux" ne pourraient pas �tre utilis�s pour un SGBD XML. D'ailleurs
des SGBD XML ca existe.

Tout SGBD a un format de stockage en fichiers. On est d'accord que pour
l'acc�s concurrentiel on ne peut travailler directement sur le fichier,
la table est donc charg�e en m�moire. Je ne vois pas pourquoi ce serait
diff�rent avec XML.
Pour les transactions, si je ne m'abuse on fait une sorte de clone de
la table (uniquement des parties concern�es) sur lequel on agit et en
fin de transaction on merge la table principale et la table temporaire
ayant servi pour la transaction. Je me trompe ? Je ne vois pas pourquoi
ce serait diff�rent avec XML.
La seule diff�rence que je vois entre XML et les autres SGBD c'est que
XML a une structure arborescente.

XML n'est qu'un format de stockage. En m�moire, c'est un DOM. On agit
donc sur le DOM, qu'on re-s�rialise ensuite (sauvegarde dans le
fichier).

Je me trompe ?

Tom.

In article <8v14de$q3$1@reader1.imaginet.fr>, "Pierre Goiffon"
<pgoiffon.invalid@webcity.fr> wrote:
>> (en d'autres termes, simplistes donc pas forc�ment tr�s juste mais
>> ca donne une id�e, XML *EST* une BdD)
> 
> En quoi XML peut il �tre compar� � une BDD ?

Sauf erreur, ton SGBD stocke tes tables dans des fichiers, c'est la
forme s�rialis�e (et propri�taire) de la repr�sentation des tables en
m�moire.
XML est une forme s�rialis�e d'un DOM. Je reviens donc sur ce que je
disais, le DOM peut-�tre consid�r� comme une BdD, XML est une fa�on de
le stocker en fichier plat.

> Un fichier CSV avec des outils donne la m�me chose non ?

A la (grosse) diff�rence pr�s qu'XML et le DOM ont des structures
arborescentes.

> La diff�rence pour moi, n�ophyte, c'est qu'avec XML on dispose d'un
> grand nombre d'outils pour passer le contenu sous des tonnes de
> formats...

Ca c'est une autre approche, une autre possibilit� d'XML.

> La BDD est pour moi indispensable, le XML est une �tape pour repartir
> vers un autre format ou �changer les donn�es avec un partenaire...

Exact. Mais une fois charg� ton XML en m�moire dans un DOM, tu peux
t'en servir comme BdD. Si tu ne fais que de l'extraction de donn�es,
XPath suffit, sinon il faudra un proc�d�, forc�ment li� (pour l'instant
au moins) au SGBD, pour entrer les donn�es. Et comme on travaille sur
la m�moire et pas sur des fichiers, il doit �tre relativement facile de
g�rer acc�s concurrentiels et transactions.

Tom.

"Tom." <ptittom@free.fr> a �crit dans le message news:
t581v8.n78.ln@ptittom.free.fr...
> XML est une forme s�rialis�e d'un DOM. Je reviens donc sur ce que je
> disais, le DOM peut-�tre consid�r� comme une BdD, XML est une fa�on de
> le stocker en fichier plat.

Hu, tu pourrais �tre plus pr�cis ? Un SGBD g�re les acc�s concurrents, la
s�curit�, etc etc etc... Je croyais que DOM �tait la description de la
structure du contenu ?

> Et comme on travaille sur
> la m�moire et pas sur des fichiers, il doit �tre relativement facile de
> g�rer acc�s concurrentiels et transactions.

? R�-inventer les SGBD ? Des solutions bien rod�es qui existent depuis
plusieurs dizaines d'ann�es ? Je ne vois pas bien pourquoi on se donnerai ce
mal ??

--

=> @ anti spam !! Merci d'enlever le .invalid pour me r�pondre...
   _________________________________________________________
  /                                                         \
  . Pierre GOIFFON                                          .
  . p  g  o  i  f  f  o  n  @  w  e  b  c  i  t  y  .  f  r .
  \_________________________________________________________/

In article <8v350g$pnh$1@reader1.imaginet.fr>, "Pierre Goiffon"
<pgoiffon.invalid@webcity.fr> wrote:

> "Tom." <ptittom@free.fr> a �crit dans le message news:
> t581v8.n78.ln@ptittom.free.fr...
>> XML est une forme s�rialis�e d'un DOM. Je reviens donc sur ce que je
>> disais, le DOM peut-�tre consid�r� comme une BdD, XML est une fa�on
>> de le stocker en fichier plat.
> 
> Hu, tu pourrais �tre plus pr�cis ? Un SGBD g�re les acc�s concurrents,
> la s�curit�, etc etc etc... Je croyais que DOM �tait la description de
> la structure du contenu ?

Oui.
J'ai dit BdD, pas SGBD ;o)
Les acc�s concurrents, c'est le SGBD qui les g�re.
Ce que je voulais dire, c'est qu'on peut avoir un SGBD qui utilise XML
comme format de stockage (et un DOM "en interne").
J'avoue que j'ai pas �t� tr�s clair sur ce coup l�...

>> Et comme on travaille sur la m�moire et pas sur des fichiers, il doit
>> �tre relativement facile de g�rer acc�s concurrentiels et
>> transactions.
> 
> ? R�-inventer les SGBD ? Des solutions bien rod�es qui existent depuis
> plusieurs dizaines d'ann�es ? Je ne vois pas bien pourquoi on se
> donnerai ce mal ??

Il ne s'agit de r�inventer les SGBD, mais d'utiliser un SGBD
"arborescent" (apr�s les SGBD relationnels et les SGBD objets).

Ensuite tout d�pend de tes besoins : si tu as besoin de faire des
insert/delete/update avec transactions et/ou acc�s concurrentiels, il
te faut un SGBD, que ce soit du relationnel, de l'objet ou de
l'"arborescent". Et les SGBD "arborescent" (qu'on appelle SGBD XML), ca
existe (j'en ai vu passer un, peut-�tre 2, sur Freshmeat.net). A toi de
choisir selon tes besoins, moi je ne peux rien dire la dessus.
Si tu ne fais que des acc�s en lecture, utiliser XPath sur un DOM peut
�tre une solution. Si tu attends beaucoup de trafic, il sera s�rement
int�ressant de g�rer le DOM en m�moire partag�e ou quelque chose comme
ca pour limiter la charge m�moire; ce qui revient presque � faire un
petit SGBD XML.

Que ce soit bien clair : j'�nonce des possibilit�s, je ne d�fend rien;
je ne connais que peu de choses sur les SGBD et leur fonctionnement
interne, je ne juge donc pas; je ne suis pas assez comp�tent et
connaisseur pour juger des performances d'une solution par rapport �
une autre.

Au fait, est-ce que ca ne pourrait pas int�resser
fr.comp.applications.sgbd ? (je laisse ca � votre appr�ciation et ne
"cruciposte" pas ni ne met de suivi particulier)

Tom.

Pierre Goiffon wrote:
 
> Une recherche dans un fichier texte est nettement plus rapide qu'une
> interrogation BDD

�a va quand m�me un peu d�pendre de la taille du fichier.


JF

-- 
�cole Ouverte de l'Internet : http://ecole.eu.org/