Bonjour,  
 
Je dois faire un petit programme et j'ai un gros doute sur comment architecturer le soft.  
 
Je vous explique donc au mieux le but du soft.  
 
De base j’exécute des appels api sur des serveurs distants et je reçois une réponse en XML.  
Je dois stocker ces réponses dans une base de donner en local (Exemple Access, Sqlite ou autre).  
Par la suite de dois faire du processing de data (en gros des requêtes sql sur la base de donnée local).
 
Ou est mon problème :
 
Voilà j'ai un doute sur la meilleure manière de transférer ma réponse XML dans la base de donnée local. Je pensais au début décoder le xml et créer une insert to dans la table correspondante, mais je ne trouve pas cela super efficient. Car je vais boucler sur la structure du XML pour recréer une requête.  
 
Il n'y aurait pas un parseur XML to SQL ?
Ou vous voyez une autre manière de faire plus intéressante ?

Ca dépend de la complexité et de la variabilité des XML.
Si tu dois faire un modèle relationnel pour tous les scénarios et que ton XML est complexe t'as pas fini. Ca te complexifie le schéma en base, l'implémentation et c'est source de bugs, donc si en plus ça ne sert à rien (pas de valeur ajoutée pour le besoin) c'est clairement à oublier.

Tu donnes trop peu de détails pour qu'on t'oriente efficacement mais comme ça, à l'arrache, je dirai de mixer les deux :
- Stocker le XML tel quel pour avoir le "détail" des données échangées.
- Matérialiser à côté dans la base tous les champs fortement structurant, nécessaires aux requêtes d'extraction que tu devras faire par exemple, et éventuellement indexer dessus là où c'est pertinent.

Je ne comprend même pas ce que tu entends par "parseur XML to SQL".
Pour manipuler du XML côté base il y a XPath mais c'est assez complexe et pas forcément justifié, voir aussi ce que propose le type "XML" supporté par certains sgbdr.

Pour le parser côté code, une fois les "bonnes" lignes extraites avec l'approche proposée ci-dessus, tu peux utiliser linq to xml.

Mais encore une fois tu donnes trop peu de détails.

Ah, et oublie Access . Si tu veux du Microsoft gratuit prend plutôt SQL Server Express (en environnement .Net type Entity Framework c'est simple à intégrer et déjà très puissant).
Si tu veux de l'open source, SQLite ou autre, y a le choix et encore une fois ça dépend du besoin et des contraintes de charge et d'hébergement...

Oui pour la base de donnée ça va être du sqlite.
 
Sinon j'utilise un xmldocument, je parcours les nodes du document pour créer une requête "insert into".  
 
Mais je suppose que l'on peut directement charger le fichier xml dans la base de donnée.  
 
Donc en théorie je gagnerais l'étape de parcourir la structure du fichier xml pour créer ma requête.
 
Actuellement
 
Requête api sur serveur distant, je recupère un flux XML. Je parcours le fichier XML pour faire un requête insert into.
 
Je suppose que l'on peut faire :
Requête api sur serveur distant , je récupère le flux xml, que le load directement dans la database (enfin je load le fichier xml complet).

Si tu passes par un ORM et que tu tiens à matérialiser en base toute la structure correspondant au XML, il n'y a qu'à ajouter sur les classes objets de la base les attributs et méthodes pour serializer/deserializer dessus directement le XML pour mapper directement XML -> BDD et réciproquement.

Une solution possible serait de faire ça en XSLT, en utilisant comme processeur Saxon et son extension SQL
Et ici un exemple plus riche de l'emploi de cette extension: http://journal.code4lib.org/articles/6486
Bon par contre, le produit est devenu payant maintenant
A+,

Merci je vais voir ce que cela donne.

Bonjour,
 
Pour reprendre la réponse de TotalRecall, Microsoft SQL Server Express en mode LocalDB est une très bonne alternative à SQLLite.
 
Et il a l'avantage de supporter un type de colonnes "xml" qui permet :
- de stocker directement un flux XML dans une colonne de la table
- de combiner SQL et XPath pour retrouver les lignes
 
D'un point de vue performances, c'est extrêmement performant, contre toute attente.

Exemple pour illustrer :

CREATE TABLE testxml
(
    id int PRIMARY KEY identity,
    DATA xml NOT NULL
);
 
INSERT INTO testxml (DATA) VALUES ('<document name="doc1"><ligne id="1">doc1 valeur ligne 1</ligne><ligne id="2">doc 1 valeur ligne 2</ligne><ligne id="3">doc 1 valeur ligne 3</ligne></document><document name="doc2"><ligne id="1">doc2 valeur ligne 1</ligne><ligne id="2">doc 2 valeur ligne 2</ligne><ligne id="3">doc 2 valeur ligne 3</ligne></document>');
INSERT INTO testxml (DATA) VALUES ('<vehicule type="voiture"><places>5</places><couleur>rouge</couleur></vehicule>');
INSERT INTO testxml (DATA) VALUES ('<vehicule type="camion"><places>2</places><couleur>blanc</couleur></vehicule>');
 
SELECT DATA.value('(/vehicule/@type)[1]', 'varchar(20)') FROM testxml WHERE DATA.exist('/vehicule/places') = '5';
 
SELECT t2.doc.value('./@name', 'varchar(20)')
FROM testxml t
CROSS apply DATA.nodes('/document') AS t2(doc);
 
SELECT t2.doc.value('.', 'varchar(20)')
FROM testxml t
CROSS apply DATA.nodes('/document/ligne') AS t2(doc);

On a beau avoir des lignes de structure XML différente, on peut toujours faire du XPath dessus et retrouver ses petits de manière performante directement avec SQL.

http://msdn.microsoft.com/fr-fr/library/ms187339.aspx