[tutoriel] Importer et exporter des données en masse au travers d'une application ASP.Net

Version imprimable

27/10/2010, 19h46
Immobilis

[tutoriel] Importer et exporter des données en masse au travers d'une application ASP.Net

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
27/10/2010, 20h28
Kaidan

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 ?
27/10/2010, 20h35
Immobilis

Salut,

Citation:

Envoyé par Kaidan

Article intéressant :ccool:.

Merci :)

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
28/02/2011, 12h03
BuchsPa

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:
22/06/2011, 06h51
iberserk

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?
22/06/2011, 07h24
Nicolas Esprit

Citation:

Envoyé par iberserk

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.

É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.
22/06/2011, 08h25
Immobilis

Salut,

Citation:

Envoyé par Nicolas Esprit

Le tuto (...) répond à un scénario donné, pas tous et c'est normal.

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.

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+
22/06/2011, 08h33
iberserk

Citation:

Je crois savoir que cela te préoccupe

Oui:ccool:

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:

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

Tu as bien de la chance 8O on doit pas avoir les même... même si les miens sont éduqués maintenant :-)

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 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...

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....
22/06/2011, 08h35
Immobilis

Citation:

Envoyé par iberserk

La par contre je ne peut que vous contredire à 100%, pour c

Ah? Dis nous :)
22/06/2011, 08h36
iberserk

Citation:

Ah? Dis nous

J'avais pas fini:cry:
22/06/2011, 08h38
iberserk

Ceci dit j'ai passé ton tuto à l'equipe de dev...
22/06/2011, 09h09
Immobilis

Citation:

Envoyé par iberserk

J'avais pas fini:cry:

Nan mais franchement, ça m’intéresse.

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
22/06/2011, 09h20
Immobilis

Citation:

Envoyé par iberserk

vous générez au minimum 15000*2=30000 requete 15000 SELECT et 15000 INSERT

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?
22/06/2011, 09h35
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.

Code:

Méthode DBA:

Importer les 15000 LIGNES du fichiers(BULK INSERT) dans une table (environ 2 secondes :-))
puis deux requetes:

Code:

INSERT INTO customer WHERE NOT EXISTS...
Code:

1 2 3 4 5 6 7 UPDATE C SET C.colonneA=TT.colonneA, C.colonneB=TT.colonneB FROM customer C INNER JOIN tableTemp TT ON TT.code=C.code
Donc deux requêtes seulement...

Ça réponds à votre question?

Donc deux
22/06/2011, 09h48
iberserk

Citation:

Il faut tout de même bien un "INSERT" pour chacun de mes enregistrements qui n'existe pas déjà, non?

Et oui...

Vous avez la nouvelle instruction MERGE qui plait beaucoup aux développeurs...

http://technet.microsoft.com/fr-fr/l.../bb510625.aspx
22/06/2011, 10h19
calagan99

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.
22/06/2011, 10h58
Immobilis

Citation:

Envoyé par iberserk

Ça réponds à votre question?

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.

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 :)
22/06/2011, 11h03
Immobilis

1 pièce(s) jointe(s)

Citation:

Envoyé par iberserk

Et oui...

Donc dans tous les cas ton scénario vérifie

Citation:

Du coups vous mettez 15000 fois à jour index et stats de votre table.

Non?

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.
http://www.developpez.net/forums/att...1&d=1308733635
22/06/2011, 11h08
iberserk

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.
22/06/2011, 11h24
youtpout978

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.
22/06/2011, 11h26
Immobilis

Citation:

Envoyé par iberserk

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?

Je leur propose des services WCF seulement. Ils seront obligés de se soumettre.

Citation:

Envoyé par iberserk

Je vous encourage à lire cela, (bien sûr c'est ici vu d'un oeil de DBA)

Ce papier a été écrit en 2005. Pas mal de choses ont changé.

Citation:

Il faut reporter la logique métier dans les procédures stockées ou les triggers.

Grand débat en perspective a ne pas ouvrir ici :D
22/06/2011, 11h31
Immobilis

Citation:

Envoyé par youtpout978

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.

C'est à tester. L'avantage de LINQ dans ce cas et d'utiliser des IQueryable. Donc tu peux tout faire.
22/06/2011, 11h39
Immobilis

Citation:

Envoyé par iberserk

Que ferez vous si

Tu peux me tutoyer ;)
Que feras-tu si on te demande de passer sous Oracle? Grâce au code tu auras juste à transférer les données.
22/06/2011, 11h47
youtpout978

L'application que j'utilise permet l'import et l'export de csv mais c'est très mal fait pour importer 600 ligne ça met + d'une minute.
J'ai déjà une idée de l'optimisation à faire, sur chaque ligne il y a l’exécution d'une soixantaine de requête (je n'imagine même pas le temps que ça mettrait avec des fichiers de 10 000 lignes), pour l'export c'est assez long puisqu'il est nécessaire de faire autant de requête pour chaque ligne.

Il y avait un treeview dans cette même appli qui effectuait une requête chargeant plusieurs centaine d'éléments et elle était effectué à chaque fois qu'on dépliait un noeud et sur chaque élément chargé on effectuait plusieurs requête résultat 50 sec d'attente à chaque fois.
Grâce à l'utilisation des listes je fais une seule fois la grosse requête et je ne fait plus que deux requêtes pour déplier un noeud et c'est en c# que je fait les comparaisons pour construire mes noeuds résultat 3 seconde pour déplier un noeud.
22/06/2011, 11h59
iberserk

Citation:

Que feras-tu si on te demande de passer sous Oracle? Grâce au code tu auras juste à transférer les données.

On me demandera dans ce cas là de réaliser le batch d'import des données... refaire la proc stock me prendra au bas mot 1minute 30...:ccool:

Quoi qu'on veuille bien essayer de nous faire croire, un client vous demandant de migrer de SQL SERVER vers ORACLE... je veux bien prendre le risque.

SQL etant normé, si c'est bien fait le travail n'est pas enorme...

Citation:

Ce papier a été écrit en 2005. Pas mal de choses ont changé.

Je ne trouve pas?

Citation:

Grand débat en perspective a ne pas ouvrir ici

Ca marche:lol:
22/06/2011, 12h03
Immobilis

C'est pas souvent qu'on voit passer des Architectes de base de données sur cette partie du forum. C'est cool :ccool:

J'espère que tu passeras souvent! :D
22/06/2011, 12h07
iberserk

Citation:

C'est pas souvent qu'on voit passer des Architectes de base de données sur cette partie du forum. C'est cool

J'espère que tu passeras souvent!

Ca c'est gentil, mais c'est un plaisir tant qu'on ne bascule pas dans lasempiternelle gueguerre EXPERT.NET/ EXPERT BDD :ccool:

Il faut dire que je viens du .NET à la base donc je connais bien les deux...

Petit test rapide:

Code:

1
2
3
4
5
6
7
8
9
IF EXISTS(SELECT * FROM sys.tables WHERE NAME='TEST')
	DROP TABLE dbo.TEST
GO
CREATE TABLE dbo.TEST
(
	TEST_ID INTEGER NOT NULL CONSTRAINT PK_TEST PRIMARY KEY CLUSTERED,
	TEST_NAME VARCHAR(50) NOT NULL
)
GO

Méthode 'LINQ':

Code:

1
2
3
4
5
6
7
8
9
10
11
INSERT INTO dbo.TEST VALUES (1,'TEST 1')
INSERT INTO dbo.TEST VALUES (2,'TEST 2')
INSERT INTO dbo.TEST VALUES (3,'TEST 3')
INSERT INTO dbo.TEST VALUES (4,'TEST 4')
INSERT INTO dbo.TEST VALUES (5,'TEST 5')
 
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR) WHERE TEST_ID=1
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR) WHERE TEST_ID=2
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR) WHERE TEST_ID=3
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR) WHERE TEST_ID=4
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR) WHERE TEST_ID=5

Regardez les plans d'executions... 5 insertions dans l'index, 5 mise à jour...

Méthode ensembliste (recréez la table au préalable...):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
INSERT INTO dbo.TEST 
SELECT 1,'TEST 1'
UNION ALL
SELECT 2,'TEST 2'
UNION ALL
SELECT 2,'TEST 3'
UNION ALL
SELECT 2,'TEST 4'
UNION ALL
SELECT 2,'TEST 5'
 
UPDATE dbo.TEST SET TEST_NAME=TEST_NAME+CAST(TEST_ID AS VARCHAR)

Une insertion dans l'index, une mise à jour...

Bien sûr cet exemple est simpliste...

Voila j'ai modifié ton code d'insertorupdate à ma sauce, je pense que cette méthode n'est pas trop mauvaise quand on insert des fichier de plusieur miliers de ligne mais quand le fichier ne contient que quelque ligne vaut mieux faire un update champs par champs:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
  /// <summary>
    /// Insère un objet Person en base ou met à jour un enregistrement existant
    /// </summary>
    /// <param name="persons">Liste d'objet Person</param>
    public static void InsertOrUpdate(IEnumerable<Persons> persons)
    {
 
        using (PersonDataContext db = new PersonDataContext())
        {
            List<Persons> inbase = db.Persons.ToList();
            List<Persons> newPerson = new List<Persons>();
            int nbInBase=inbase.Count;
            foreach (var p in persons)
            {
                 // Si le Guid est vide ou la base est vide
                if (p.PersonId == Guid.Empty || nbInBase == 0)
                {
                    // Si le Guid est vide
                    if (p.PersonId == Guid.Empty)
                    {
                        // On génère un nouvel identifiant
                        p.PersonId = Guid.NewGuid();
 
                    }
                    // On l'ajoute a la liste des insertions
                    newPerson.Add(p);
                }
                else
                {
                    // sinon on recherche s'il est déjà en base
                    if (inbase.Exists(per => per.PersonId == p.PersonId))
                    {
                        // s'il est en base on récupère la personne avec le même id
                        var pInBase = inbase.Single(per => per.PersonId == p.PersonId);
 
                        // si son nom ou son prénom diffère on les change
                        if (!(pInBase.FirstName == p.FirstName && pInBase.LastName == p.LastName))
                        {
                            pInBase.FirstName = p.FirstName;
                            pInBase.LastName = p.LastName;
                        }
                    }
                    else
                    {
                        // s'il n'est pas en base on l'ajoute à la liste des insertions
                        newPerson.Add(p);
                    }
                }
 
            }
 
            // si la liste des insertions n'est pas vide
            if (newPerson.Count > 0)
            {
                // on insère toutes les données en base
                db.Persons.InsertAllOnSubmit(newPerson);
            }
            // on valide les modifications
            db.SubmitChanges();
        }
 
 
    }

Sinon ton code est vraiment efficace au niveau de l'export :ccool:

Par contre dans ton exemple un coup tu as une table Persons et un autre coup c'est Person donc si on copie ton code à l'identique on a des erreurs et il manque la méthode load (même si elle est pas compliqué a codé).

Merci pour l'article ;)

24/06/2011, 17h08
iberserk

Bonjour.

A quoi sert cette partie?:

Citation:

// s'il est en base on récupère la personne avec le même id
var pInBase = inbase.Single(per => per.PersonId == p.PersonId);

// si son nom ou son prénom diffère on les change
if (!(pInBase.FirstName == p.FirstName && pInBase.LastName == p.LastName))
{
pInBase.FirstName = p.FirstName;
pInBase.LastName = p.LastName;
}

Vous faites ce traitement mais vous ne gérez ensuite que les insert?
24/06/2011, 18h33
youtpout978

au submitchanges ils s'occupent tout seul de faire les maj
26/06/2011, 16h03
iberserk

Citation:

au submitchanges ils s'occupent tout seul de faire les maj

Sauf erreur de ma part le tracking intégré à LINQ TO SQL se charge de déterminer les colonnes à mettre à jour, cette vérification n'est pas nécessaire...
26/06/2011, 16h53
youtpout978

le submitchanges est nécessaire pour apporter les modification en base sinon la modification n'est effective qu'en mémoire
http://msdn.microsoft.com/fr-fr/library/bb399378.aspx
27/06/2011, 08h56
iberserk

Citation:

e submitchanges est nécessaire pour apporter les modification en base sinon la modification n'est effective qu'en mémoire
http://msdn.microsoft.com/fr-fr/library/bb399378.aspx

Je neparle pas du submit changes mais du test que vous faites pour savoir si les données ont changées...

C'est cette partie qui s'occupe de faire les mise à jour :
Code:

1 2 3 4 5 6 7 8 9 // s'il est en base on récupère la personne avec le même id var pInBase = inbase.Single(per => per.PersonId == p.PersonId); // si son nom ou son prénom diffère on les change if (!(pInBase.FirstName == p.FirstName && pInBase.LastName == p.LastName)) { pInBase.FirstName = p.FirstName; pInBase.LastName = p.LastName; }
en récupérant ma liste

Code:

List<Persons> inbase = db.Persons.ToList();

dans le datacontext courant

Code:

using (PersonDataContext db = new PersonDataContext())

et en effectuant une modification sur ces données linq comprendra que c'est ses données qui ont été modifiées

27/06/2011, 09h35
iberserk

Je vous ai bien compris, ce que je veux dire c'est que ca:

Citation:

if (!(pInBase.FirstName == p.FirstName && pInBase.LastName == p.LastName))

Est pour moi inutile... enlevez ce test et si il n'y a aucune modif, le context ne fera pas d'UPDATE...

d'accord merci j'avais peur que de faire ça fasse perdre du temps mais si ça modifie rien bein tant mieux :ccool:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
  /// <summary>
    /// Insère un objet Person en base ou met à jour un enregistrement existant
    /// </summary>
    /// <param name="persons">Liste d'objet Person</param>
    public static void InsertOrUpdate(IEnumerable<Persons> persons)
    {
 
        using (PersonDataContext db = new PersonDataContext())
        {
            List<Persons> inbase = db.Persons.ToList();
            List<Persons> newPerson = new List<Persons>();
            int nbInBase=inbase.Count;
            foreach (var p in persons)
            {
                 // Si le Guid est vide ou la base est vide
                if (p.PersonId == Guid.Empty || nbInBase == 0)
                {
                    // Si le Guid est vide
                    if (p.PersonId == Guid.Empty)
                    {
                        // On génère un nouvel identifiant
                        p.PersonId = Guid.NewGuid();
 
                    }
                    // On l'ajoute a la liste des insertions
                    newPerson.Add(p);
                }
                else
                {
                    // sinon on recherche s'il est déjà en base
                    if (inbase.Exists(per => per.PersonId == p.PersonId))
                    {
                        // s'il est en base on récupère la personne avec le même id
                        var pInBase = inbase.Single(per => per.PersonId == p.PersonId);
 
                            pInBase.FirstName = p.FirstName;
                            pInBase.LastName = p.LastName;
 
                    }
                    else
                    {
                        // s'il n'est pas en base on l'ajoute à la liste des insertions
                        newPerson.Add(p);
                    }
                }
 
            }
 
            // si la liste des insertions n'est pas vide
            if (newPerson.Count > 0)
            {
                // on insère toutes les données en base
                db.Persons.InsertAllOnSubmit(newPerson);
            }
            // on valide les modifications
            db.SubmitChanges();
        }
 
 
    }

29/06/2011, 22h13
iberserk
youtpout978, quel est le contexte de votre batch?

Un fichier CSV?

Sachez qu'une procédure stockée faisant un BULKINSERT (bulkinsert permet de charger en masse un fichier plat dans une table) de votre fichier CSV dans une table de travail puis deux requêtes:
Code:

1 2 3 4 5 6 7 8 UPDATE C SET C.firstName=T.firstName, C.lastName=T.lastname FROM customer C INNER JOIN TABLETRAVAIL T ON T.ID=C.ID WHERE C.firstname<>T.firstname OR C.lastname<>T.lastname
Pour mettre a jour tous les customers existants d'un coups
Puis

Code:

INSERT INTO customer(firstname,lastname) SELECT firstname,lastname FROM TABLETRAVAIL T WHERE NOT EXISTS(SELECT * FROM customer WHERE id=T.id)

pour insérer les nouveaux customer

Prendrait au bas mots 1 secondes? peut être deux?...

Le bulk insert:

http://msdn.microsoft.com/fr-fr/library/ms188365.aspx
29/06/2011, 22h26
youtpout978

là c'était juste pour améliorer le code de de son exemple, l'appli que j'utilise est tellement bien faite que tu deviendrais aveugle en voyant l'application et la base :aie:
30/06/2011, 09h07
iberserk

A ok pardon :ccool:

Fuseau horaire GMT +2. Il est actuellement 09h13.