🚀 go-pugleaf

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.