2010-09-16 18 views
2

Je suis censé faire la jachère:
1) lire un énorme fichier XML (700MB ~ 10 millions d'éléments);
2) analyser en préservant l'ordre;
3) créer un fichier texte (un ou plusieurs) avec des instructions d'insertion SQL pour le charger en bloc sur la base de données;
4) écrire les tuples relationnels et les réécrire en XML.Lecture et écriture XML en tant que données relationnelles - meilleures pratiques

Je suis ici pour échanger quelques idées sur le meilleur moyen de le faire (== fast fast fast ...). Je vais utiliser C# 4.0 et SQL Server 2008.

Je crois que XmlTextReader est un bon début. Mais je ne sais pas si cela peut gérer un fichier aussi énorme. Est-ce qu'il charge tout le fichier quand est instancié ou contient juste la ligne de lecture réelle dans la mémoire? Je suppose que je peux faire un while(reader.Read()) et ça devrait aller.

Quelle est la meilleure façon d'écrire les fichiers texte? Comme je devrais préserver l'ordre du XML (en adoptant un schéma de numérotation), je devrai garder quelques parties de l'arbre en mémoire pour faire les calculs etc ... Dois-je parcourir avec stringbuilder?

Je vais avoir deux scénarios: un où chaque noeud (élément, attribut ou texte) sera dans la même table (ie, sera le même objet) et un autre scénario où pour chaque type de noeud (juste ces trois types , pas de commentaires etc ..) Je vais avoir une table dans le DB et une classe pour représenter cette entité.

Ma dernière question spécifique est la qualité du DataSet ds.WriteXml? Est-ce qu'il va gérer 10M tuples? Peut-être son meilleur pour apporter des morceaux de la base de données et utiliser un XmlWriter ... Je ne sais vraiment pas.

Je suis en train de tester toutes ces choses ... Mais j'ai décidé de poster cette question pour vous écouter les gars, en sautant votre expertise peut m'aider à faire ces choses plus correctement et plus rapidement.

Merci à l'avance,

Pedro Dusso

+0

Est-ce que quelqu'un fait plus d'analyse syntaxique? – kurosch

+0

J'utilise 'XmlReader' dans .NET et ne manque pas SAX du tout. –

+0

Que signifie SAX? –

Répondre

1

Devinez quoi? Vous n'avez pas de problème SQL Server. Vous avez un problème XML!

Face à votre situation, je n'hésiterais pas. J'utiliserais Perl et l'un de ses nombreux modules XML pour analyser les données, créer de simples fichiers délimités par des tabulations ou d'autres fichiers à charger en bloc, et bcp les fichiers résultants.

Utilisation du serveur pour analyser votre XML a de nombreux inconvénients:

  1. Pas rapide, plus que probable
  2. messages d'erreur Positivement inutiles, dans mon expérience
  3. Debugger
  4. Nulle part où aller quand l'un des cas ci-dessus s'avère être vrai

Si vous utilisez Perl, vous avez ligne par ligne le traitement et le débogage, les messages d'erreur destinés à guider un programmeur, ainsi que de nombreuses alternatives si votre premier choix de paquet ne s'avère pas faire le travail.

Si vous faites ce genre de travail souvent et ne connaissez pas Perl, apprenez-le. Il vous remboursera plusieurs fois.

5

j'utiliser le SQLXML Bulk Load Component pour cela. Vous fournissez un schéma XSD spécialement annoté pour votre XML avec des mappages incorporés à votre modèle relationnel. Il peut ensuite charger en vrac les données XML rapidement.

Si votre fichier XML n'a pas de schéma, vous pouvez en créer un à partir de Visual Studio en chargeant le fichier et en sélectionnant Créer un schéma dans le menu XML. Vous devrez cependant ajouter les mappages à votre modèle relationnel. This blog a quelques messages sur la façon de le faire.

+0

Puis-je créer ce XSD par programme? Je recevrai un fichier XML non identifié, sans schéma joint. –

+0

J'ai étudié la charge en bloc SQLXML. C'est pour un scénario très spécifique, où vous avez déjà un xsd très bien construit. J'ai beaucoup de lignes directrices et de limites. Il sera difficile de générer un bon schéma xsd pour le charger après avoir méconnu le fichier qui viendra :( –