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...
Message édité par TotalRecall le 15-08-2014 à 18:42:30
---------------
Topic .Net - C# @ Prog