Version imprimable
Salut,
Voici un petit tutoriel: Importer et exporter des données au travers d'une application ASP.Net
Il explique comment utiliser la sérialisation/desérialisation XML et Excel 2007 pour exporter et importer des données en masses dans une base de données.
Qu'en pensez-vous? N'oubliez pas de "Noter la discussion" pour évaluer l'article :ccool:
Merci d'avance :ccool:
A+
Immo
Article intéressant :ccool:.
Je me demandais juste ce qu'il se passe lorsqu'on tente d'importer ou d'exporter un volume très important de données, trop important en tout cas pour que l'exécution puisse être réalisée dans la durée maximale d'exécution d'une requête ASP.NET (httpRuntime / executionTimeout). C'est une contrainte, lorsqu'on fait du traitement de masse, à ne pas ignorer sur le web non ?
Salut,
Merci :)Citation:
Envoyé par Kaidan
Dans la mesure où la durée du timeout peut être étendue, il n'y a pas vraiment de limites.
Dans l'absolu, c'est le temps de téléchargement du fichier qui peut être un peu long. Pour accélérer cette étape, on peut ziper le fichier. Comme XML est du texte, le taux de compression devrait être satisfaisant.
Sinon, pour le reste du processus, on peut "passer la main" et ne pas attendre la fin de la mise à jour. Ou bien, on peut imaginer sauvegarder le fichier sur le serveur et programmer une tâche planifiée sur un programme console pour faire la mise à jour.
A+
Immo
Merci beaucoup pour ce tutoriel très intéressant et aussi très utile :)
Si tu n'avais pas écrit ce tutoriel, je pense que j'aurais perdu encore bien plus de temps pour terminer mon travail.
En tous cas un grand merci de ma part :ccool:
Bonjour,
En général les SGBD proposent des solutions d'import export de fichier qui seront surement beaucoup plus rapide...
Avez vous pensé à des tests de performances? je doute importer un fichier/table de plusieurs giga puissent être obtenu avec des performances acceptable?
Le tuto d'Immobilis répond à un scénario donné, pas tous et c'est normal. Mais il a surtout le mérite d'être clair et didactique.Citation:
Envoyé par iberserk
Évidemment pour des scénarios plus complexes, ou bien pour une forte volumétrie, on se penchera plutôt vers des packages SSIS par exemple.
Salut,Tout à fait. Pour la simple et bonne raison qu'il ne viendrait pas à l'esprit d'un développeur d'utiliser un WebForm pour télécharger un fichier de plusieurs Giga.Citation:
Envoyé par Nicolas Esprit
Cet outil est destinée à un utilisateur final. J'ai souvent eu des situations où les utilisateurs devaient mettre à jour de nombreuses données et pour lesquels un WebForm ne répondait pas au besoin car trop lent. Leur permettre de travailler avec un tableur (Excel) est très confortable. Sinon, je ne crois pas non plus qu'un utilisateur final ait les moyens logiciels pour exploiter un fichier de cette taille sur son ordi.
Enfin, d'un point de vue base de données (l'insertion des enregistrements) si la table est correctement indexée, il ne devrait pas y avoir de soucis. Le DataContext reste ouvert en dehors de la boucle foreach. Cela permet d'ouvrir une seule connexion. Je crois savoir que cela te préoccupe ;)
A+
Oui:ccool:Citation:
Je crois savoir que cela te préoccupe
Bien sûr très bon tuto,je ne le remettais pas en question mais comme on y parlait 'd'insertion en masse' j'ai fait l'amalgame avec des volumétries déjà moyennes...
En revanche je souhaiterais rebondir là dessus:
Tu as bien de la chance 8O on doit pas avoir les même... même si les miens sont éduqués maintenant :-)Citation:
Pour la simple et bonne raison qu'il ne viendrait pas à l'esprit d'un développeur d'utiliser un WebForm pour télécharger un fichier de plusieurs Giga
La par contre je ne peut que vous contredire à 100%, pour ca utiliser un code client est une catastrophe, pour allez je vais être gentil 15000 enregistrements entre le rapatriement des objets (select pour savoir si on le modifie ou si on l'insert...) vous générez au minimum 15000*2=30000 requete 15000 SELECT et 15000 INSERT... tout celà transitant joyeusement par le réseau qui plus est...Citation:
Enfin, d'un point de vue base de données (l'insertion des enregistrements) si la table est correctement indexée, il ne devrait pas y avoir de soucis. Le DataContext reste ouvert en dehors de la boucle foreach. Cela permet d'ouvrir une seule connexion.
La première chose que j'ai refaite dans ma société actuelle est de refaire TOUT les imports (clients, articles etc) d'un ERP vers un site EBUSINESS fait en LINQ!!!!
Je suis passé pour 400000 enregistrements d'une dizaine d'heures (oui!) à 53 secondes....
Ah? Dis nous :)Citation:
Envoyé par iberserk
J'avais pas fini:cry:Citation:
Ah? Dis nous
Ceci dit j'ai passé ton tuto à l'equipe de dev...
Nan mais franchement, ça m’intéresse.Citation:
Envoyé par iberserk
Personnellement, j'utilise surtout les compteurs de performance de Windows pour suivre les compteurs "General Statistics" du serveur SQL. Qu'est-ce que tu utilises? Sachant que le gain de temps d’exécution est évidement :P
Comme je ne suis pas DBA. Peux-tu me dire comment cela se traduit au final pour le serveur de base de données? Il faut tout de même bien un "INSERT" pour chacun de mes enregistrements qui n'existe pas déjà, non? Comment traduire efficacement côté SQL le test pour mettre à jour au lieu d'insérer?Citation:
Envoyé par iberserk
Et bien justement il ne faut pas le faire Côté code.
Pour résumer faire cela en utilisant LINQ(dans les grandes lignes):
->J'ouvre mon fichier ligne par ligne (déjà çà... ca doit faire tiquer un fichier peut se traiter de manière ensembliste par des requêtes SQL, ce que ne permet pas le code client)
Pour chaque ligne (disons des Utilisateur):
J'instancie mon objet monUser utilisateur via LINQ (un bon SELECT * du coups...)
Je fais mon test:
Si monUser est null j'instancie un nouvel objet pour faire mon insert...
Sinon je met à jour les données de l'objet instancié avec les données de ma ligne...
Je fais donc cela 15000 fois (15000 lignes dans le fichier)...
Et je fais un submitChanges qui va faire 15000 requêtes (INSERT ou UPDATE)
Donc:
1-Vous avez remonté 15000 lignes de la base de données.... une par une par le réseau (donc 15000 fois la latence réseau etc).
Vous avez instancé 15000 objets...
Et vous avez envoyé 15000 INSERT dans la base.
Du coups vous mettez 15000 fois à jour index et stats de votre table.
Importer les 15000 LIGNES du fichiers(BULK INSERT) dans une table (environ 2 secondes :-))Code:Méthode DBA:
puis deux requetes:
Code:INSERT INTO customer WHERE NOT EXISTS...
Donc deux requêtes seulement...Code:
2
3
4
5
6
7UPDATE C SET C.colonneA=TT.colonneA, C.colonneB=TT.colonneB FROM customer C INNER JOIN tableTemp TT ON TT.code=C.code
Ça réponds à votre question?
Donc deux
Et oui...Citation:
Il faut tout de même bien un "INSERT" pour chacun de mes enregistrements qui n'existe pas déjà, non?
Vous avez la nouvelle instruction MERGE qui plait beaucoup aux développeurs...
http://technet.microsoft.com/fr-fr/l.../bb510625.aspx
Article intéressant.
En effet, il ne concerne que certains scénarii mais me paraît tout à fait utile.
Pour ce qui est de l'instruction MERGE, attention, elle n'est présente sous SQL Server que depuis la version 2008. Et de ce que je peux voir, il y a encore de très nombreux projets sous 2005 voire même 2000.
On peut cela dit se débrouiller avec l'instruction OUTPUT dans ces versions pour réaliser à peu près la même chose.
Point de vue très intéressant. Le code ne peut évidement pas lutter contre un Bulk Insert. Incontestablement, le code que je propose génère beaucoup de requêtes. Il y a forcement des trames qui passent et occupent de la bande passante. Ce sont les incompressibles.Citation:
Envoyé par iberserk
Cependant, le bulk insert correspond lui aussi à un besoin métier très spécifique. La création du fichier de bulk, son dépôt sur un partage, etc. sont autant de contraintes qu'il faut prendre en compte. J'ai rarement eu besoin de faire appel à lui. A l'occasion d'un besoin de mise à jour de millions d'enregistrements, nous avons fait appel au SQL Server Service Broker.
Par ailleurs, j'ai une certaine réticence à mettre trop de logique hors du code. Dans le cas du tutoriel (simpliste), il serait peut-être avisé de récupérer la totalité de la table (15000 enregistrements sont négligeables), préparer la mise à jour et l'insertion par le code et renvoyer les données. Par ailleurs, le téléchargement de ces données pourrait très bien déclencher d'autres processus. De plus, il ne faut pas oublier non plus que le code permet facilement de traiter les enregistrements dont le traitement auraient pu échouer.
Sinon, il faudrait tester tout cela en environnement de prod (sur mon portable c'est pas top). Localement, je ne génère que 5 ou 6 connections. Sans compter que ma requête LINQ n'est pas compilée.
Je passerai un petit peu de temps pour prendre en compte ton scénario :)
Donc dans tous les cas ton scénario vérifieCitation:
Envoyé par iberserk
Non?Citation:
Du coups vous mettez 15000 fois à jour index et stats de votre table.
Ci dessous les compteurs de perf. J'ai SQL Server 2008 et le compteur "Connection Reset/sec" est nouveau. Faut que je vois ce qu'il indique.
Je ne pousserais pas le débat plus loin car à par peut être pour la notion de logger les lignes en erreurs je suis en désaccord sur tout le reste...
Les performances passées quelques dizaine de milliers de lignes sont d'un autre monde et traiter de la données et assurer leur cohérence... c'est la rôle de la base...
Que ferez vous si d'autres applications développées par d'autres personnes commencent à 'taper' dans votre base et la vérole complétement car ils n'ont pas les mêmes règles métiers embarquées dans LEUR code client?
Mais je suis confiant, les tests que vous comptez faire appuieront ma position.
J'ai une problématique similaire dans le projet sur lequel je travaille, je voulais savoir si le faite de travailler avec des listes ne diminuerai pas le temps d’exécution.
On utiliserai 3 listes:
-une correspondante à tous les champs dans la base on fait un select dans la base pour récupérer tous les lignes de la table qui nous intéresse (et que les champs qui nous intéresse pour la comparaison)
-la seconde correspondante au mise à jour
-la troisième aux insertions
Comme ça à chaque ligne de notre fichier on fait la comparaison avec la première liste et ça nous permettra de déterminer dans quel liste placer cette ligne.
Une fois que tout est terminé on fait un insertallonsubmit de la liste d'insertion et on fait les update grâce à la liste de mise à jour.