IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

VB.NET Discussion :

Mode connecté ou mode déconnecté ?


Sujet :

VB.NET

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut Mode connecté ou mode déconnecté ?
    Bonjour,

    J'ai une grande question qui me taraude depuis 2-3 semaines. Je travaille sous deux types de BD : Access et SQL-Server. Il apparaît que sous Access le mode connecté marche correctement même si j'ai beaucoup traitements (1600 livres * 300 requêtes -> C'est le plus lourd, environ 2h30 de traitement) à effectuer dessus. Par contre, sur une base SQL Server c'est plus tendu (400 enregistrements * 300 requêtes-> 3h....)

    Il semblerait que le mode connecté de VS sur SQL Server ne soit pas trop adapté. Pensez-vous que j'optimiserais le travail en mode déconnecté ?

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 753
    Points
    39 753
    Par défaut
    Il n'y a pas vraiment de réponse toute faite, tout dépend des traitements que tu effectues.

    Si c'est les requêtes d'insertion et de mise à jour qui prennent du temps, le mode déconnecté ne t'apportera pas grand chose : tu feras tes traitements en mémoire, mais après il faudra encore effectuer des requêtes pour mettre à jour la BDD.

    Après, s'il y a des requêtes que tu effectues souvent et qui renvoient les mêmes données, ça peut être intéressant de précharger ces données dans un DataSet pour y accéder plus rapidement

  3. #3
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 177
    Points : 25 122
    Points
    25 122
    Par défaut
    vous pouvez m'expliquez tous les 2 votre vision de connecté/déconnecté ?

    (@tomlev je t'ai pas déjà saoulé avec ca ? (ca = que je pense que le mode connecté n'existe pas avec sqlclient.*))

    @sebnantes : le temps d'exécution dépend aussi (et surtout ?) du modèle de données et de la facon d'écrire les requetes

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 753
    Points
    39 753
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    vous pouvez m'expliquez tous les 2 votre vision de connecté/déconnecté ?
    Je sais pas si c'est la définition "officielle", mais ce que j'appelle le mode déconnecté, c'est quand on travaille en mémoire sur un DataSet, et qu'on met ensuite à jour la BDD avec un DbDataAdapter. Le mode connecté, c'est quand on travaille directement sur la BDD à coups de DbCommand/DbDataReader

  5. #5
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 177
    Points : 25 122
    Points
    25 122
    Par défaut
    si, ca a l'air d'etre la définition officielle, mais c'est pas celle que je croyais
    (enfin wikipedia peut raconter des conneries aussi)

    m'enfin ca reste étrange de différencier un dataset/Dataadapter de command/datareader alors que le dataset se rempli grace à un datareader et le dataadapter effectue les modifications grace à des command ...

    le mode connecté sous vb6 était à mon sens un vrai mode connecté, un recordset pouvait aller dans tous les sens et se mettre à jour de manière bidirectionnelle
    le datareader de .net ne va qu'en avant et ne permet pas de modification, et personne ne garde un datareader ouvert longtemps, meme sans dataset, on lit les données et on le ferme, on traite après

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    826
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juin 2006
    Messages : 826
    Points : 1 120
    Points
    1 120
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    si, ca a l'air d'etre la définition officielle, mais c'est pas celle que je croyais
    (enfin wikipedia peut raconter des conneries aussi)

    m'enfin ca reste étrange de différencier un dataset/Dataadapter de command/datareader alors que le dataset se rempli grace à un datareader et le dataadapter effectue les modifications grace à des command ...
    bah il faut bien se connecter au moins une fois, pour avoir un mode deconnecté avec de vraies données.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    Edit : Oups, il y a eu plein de réponses le temps que je formule correctement mon message ^^

    @tomlev

    Ton deuxième paragraphe répond (hélas....) à mon problème. J'ai effectivement plein d'insertion/update qui sont effectués.

    Par contre, tu sous-entends qu'il est intéressant pour moi de placer les données que je balaye à l'aide d'un while (récupérer dans un reader, dans mes exemples cela équivaut au 1600 enregistrements de départ) dans un dataSet ?

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 753
    Points
    39 753
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    m'enfin ca reste étrange de différencier un dataset/Dataadapter de command/datareader alors que le dataset se rempli grace à un datareader et le dataadapter effectue les modifications grace à des command ...
    oui, mais entre le moment où tu remplis ton dataset et celui où tu mets à jour la BDD, tu n'accèdes plus à la BDD, tu peux même fermer la connexion, d'où le nom "déconnecté" (enfin je suppose)

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    Citation Envoyé par tomlev Voir le message
    oui, mais entre le moment où tu remplis ton dataset et celui où tu mets à jour la BDD, tu n'accèdes plus à la BDD, tu peux même fermer la connexion, d'où le nom "déconnecté" (enfin je suppose)
    Oui c'est ça ^^, j'ai vu ce principe dans d'autres langages. Le mode déconnecté est en fait une copie en "local" des données dans des structures adaptées à tes besoins.

  10. #10
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 177
    Points : 25 122
    Points
    25 122
    Par défaut
    @tomlev y a des gens (sensés) qui ne ferment pas la connexion quand ils ont eut leurs données !?


    @sebnantes, il nous faudrait une explication de ce que tu fais exactement si tu veux qu'on voit si c'est optimisable
    il est dans bien des cas possible de réduire 1000 requetes de 5 secondes en une seule requete de 30 secondes

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    @sebnantes, il nous faudrait une explication de ce que tu fais exactement si tu veux qu'on voit si c'est optimisable
    il est dans bien des cas possible de réduire 1000 requetes de 5 secondes en une seule requete de 30 secondes
    Le soucis, vois-tu, c'est que je travaille sur un logiciel qui a été remanié maintes et maintes fois (changement de langages, plusieurs personnes qui ont travaillé dessus (sans commenter quoique ce soit,....), qui ne dispose pas d'une base de données relationnelle, qui fait des insertions/update tout le temps, qui reste connecté en permanence à la base(oui, oui ça répond à la question que tu posais à Tomlev ^^) et pour le moment, je ne peux pas faire une connexion/déconnexion de la base....bref, j'essaie d'optimiser tout cela avec tout ce patacaisse.

    Donc, c'est pour cette raison que je ne suis pas rentré dans les détails

  12. #12
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    948
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 948
    Points : 1 111
    Points
    1 111
    Par défaut
    @tomlev y a des gens (sensés) qui ne ferment pas la connexion quand ils ont eut leurs données !?
    Pourquoi fermer systematiquement la connexion? Pour un logiciel qui fait essentiellement du SQL, tu peux très bien ouvrir la connexion au début du programme et le fermer à la fin. En quoi ce serait genant?

    Pensez-vous que j'optimiserais le travail en mode déconnecté ?
    Il n'y a pas de réponse prédéfinie pour ce type de question, tout dépend de l'architecture. Si tu as un serveur SQL rapide et une super connexion avec un poste client pourri, tu as tout interet à faire du mode connecté pour que les traitements se fassent sur le serveur. Si tu as un serveur surchargé, un réseau qui rame, et un poste client de la mort qui tue, tu as tout interet a faire tes traitements en local (déconnecté).

    Il y a en revanche 2 grosses différences entre les modes connectés et déconnectés : en mode connecté tu auras toujours les "vraies" données, alors qu'ne mode déconnecté, si la base de donnée change pendant la durée de ton traitement, tu ne le sauras jamais.
    L'autre différence, qui est liée à ca, c'est qu'ne mode connecté tu peux avoir des LOCK sur tes tables ce qui au final peut parfois planter les requetes MAIS c'est salvateur parce que ca évite que n'importe quoi soit fait sur la base.

    Ceci étant dit, les temps annoncés sont horriblement longs, pour 400 enregistrements, tu dis que chaque requete prend en moyenne plus de 30 secondes, c'est énormissime, non? Tu peux donner une exemple de requete qui rame?

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    Citation Envoyé par Flamby38 Voir le message
    Ceci étant dit, les temps annoncés sont horriblement longs, pour 400 enregistrements, tu dis que chaque requete prend en moyenne plus de 30 secondes, c'est énormissime, non? Tu peux donner une exemple de requete qui rame?
    Ce n'est pas une requête en particulier qui rame. Pour la base où j'ai 400 enregistrements, si j'utilise le programme par paquet de 100, cela mets beaucoup moins de temps au final. En voyant cela, je me suis demandé si cela ne venait pas du pools de connexions de SQL Server, mais cela fait partie des choses que je ne maîtrise pas encore très bien, et je n'arrive pas à voir où placer du code pour les libérer....

  14. #14
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 753
    Points
    39 753
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    @tomlev y a des gens (sensés) qui ne ferment pas la connexion quand ils ont eut leurs données !?
    Citation Envoyé par Flamby38 Voir le message
    Pourquoi fermer systematiquement la connexion? Pour un logiciel qui fait essentiellement du SQL, tu peux très bien ouvrir la connexion au début du programme et le fermer à la fin. En quoi ce serait genant?
    Effectivement, ça dépend du type d'application... pour une application de type transactionnel, genre un site web, c'est clair qu'il faut fermer la connexion à chaque fois. Par contre, pour un traitement de masse en mode batch, c'est sans doute pas nécessaire, et même dommageable pour les performances

  15. #15
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 177
    Points : 25 122
    Points
    25 122
    Par défaut
    enfin avec des tables quelques centaines de lignes et 3h de traitement, le tout en saturant un pool de connexion, je pencherais pour du codage avec les pieds ...

  16. #16
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    Citation Envoyé par Pol63 Voir le message
    enfin avec des tables quelques centaines de lignes et 3h de traitement, le tout en saturant un pool de connexion, je pencherais pour du codage avec les pieds ...
    J'aurais penser plus à coder avec des moufles mais les pieds c'est pas mal aussi ^^

    Hum que te répondre mis à part .... oui .... mais pas le choix ... ou alors il faudrait que l'on m'autorise à prendre une semaine complète (voir plus) pour remanier cette fonctionnalité complétement... mais c'est pas gagné

  17. #17
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    948
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 948
    Points : 1 111
    Points
    1 111
    Par défaut
    Moi je suis d'accord pour dire que c'est codé avec des moufles aux pieds (pour votre sécurité, n'essayez pas ca chez vous), franchement 400 enregistrement c'est ridicule pour une base de données.

    Il y a un outil très pratique pour voir ce qui se passe sur SQL server, c'est le profiler. je te conseille de te pencher sur ce logiciel (c'est fourni avec SQL server, ca se lance depuis le bouton outils de management studio je crois). il va te dire ce que voit et fait le serveur SQL. Ainsi tu verras si : il y a beaucoup de connexions qui s'ouvrent mais ne se ferment pas / il y a quelques requetes dans le tas qui sont longues et pas d'autres / etc...

    Si tu regardes le code de l'appli vérifie que les objets instanciés sont bien libérés avec un dispose (je parle des objets "importants", genre datatable ou connexions), et que pour chaque ouverture de connexion tu as une fermeture de connexion qui correspond.

    Si je devais jouer à madame Soleil je dirais qu'il y a dans le programme une boucle qui est mal faite et qui accumule des lenteurs au fur et à mesure.

  18. #18
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    310
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 310
    Points : 347
    Points
    347
    Par défaut
    @Flamby Je me sers déjà de sql profiler, et les requêtes s'enchaînent sans problème. A un moment (de mémoire vers le 120-130ème enregistrements), le message suivant se répète pendant un temps non-fixe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    exec sp_reset_connection 
    go
    declare @p1 nvarchar(64)
    set @p1=N'C.0.9.45'
    exec GetDBVersion @DBVersion=@p1 output
    select @p1
    go
    declare @p1 nvarchar(64)
    set @p1=N'C.0.9.45'
    exec GetDBVersion @DBVersion=@p1 output
    select @p1
    go
     
                                                declare @BatchID uniqueidentifier
     
                                                set @BatchID = NEWID()
     
                                                UPDATE [Event] WITH (TABLOCKX)
                                                    SET [BatchID] = @BatchID,
                                                    [ProcessStart] = GETUTCDATE(),
                                                    [ProcessHeartbeat] = GETUTCDATE()
                                                FROM (
                                                    SELECT TOP 2 [EventID] FROM [Event] WITH (TABLOCKX) WHERE [ProcessStart] is NULL ORDER BY [TimeEntered]
                                                    ) AS t1
                                                WHERE [Event].[EventID] = t1.[EventID]
     
                                                select top 2
    	                                            E.[EventID],
    	                                            E.[EventType],
    	                                            E.[EventData]
                                                from
    	                                            [Event] E WITH (TABLOCKX)
                                                where
    	                                            [BatchID] = @BatchID
                                                ORDER BY [TimeEntered]
     
    go
     
                                        declare @BatchID uniqueidentifier
     
                                        set @BatchID = newid()
     
                                        UPDATE [Notifications] WITH (TABLOCKX)
                                            SET [BatchID] = @BatchID,
                                            [ProcessStart] = GETUTCDATE(),
                                            [ProcessHeartbeat] = GETUTCDATE()
                                        FROM (
                                            SELECT TOP 2  [NotificationID] FROM [Notifications] WITH (TABLOCKX) WHERE ProcessStart is NULL and
    	                                    (ProcessAfter is NULL or ProcessAfter < GETUTCDATE()) ORDER BY [NotificationEntered]
                                        ) AS t1
                                        WHERE [Notifications].[NotificationID] = t1.[NotificationID]
     
                                        select top 2
    		                                    -- Notification data
    		                                    N.[NotificationID],
    		                                    N.[SubscriptionID],
    		                                    N.[ActivationID],
    		                                    N.[ReportID],
    		                                    N.[SnapShotDate],
    		                                    N.[DeliveryExtension],
    		                                    N.[ExtensionSettings],
                                                N.[Locale],
    		                                    N.[Parameters],
    		                                    N.[SubscriptionLastRunTime],
    		                                    N.[ProcessStart],
    		                                    N.[NotificationEntered],
    		                                    N.[Attempt],
    		                                    N.[IsDataDriven],
    		                                    SUSER_SNAME(Owner.[Sid]),
    		                                    Owner.[UserName],
    		                                    -- Report Data
    		                                    O.[Path],
    		                                    O.[Type],
    		                                    SD.NtSecDescPrimary,
                                                N.[Version],
                                                Owner.[AuthType]
    	                                    from 
    		                                    [Notifications] N with (TABLOCKX) inner join [Catalog] O on O.[ItemID] = N.[ReportID]
    		                                    inner join [Users] Owner on N.SubscriptionOwnerID = Owner.UserID
    		                                    left outer join [SecData] SD on O.[PolicyID] = SD.[PolicyID] AND SD.AuthType = Owner.AuthType
    	                                    where 
    		                                    N.[BatchID] = @BatchID
                                        ORDER BY [NotificationEntered]
     
    go
    et ensuite ça repart.

    Pour la boucle merdeuse, je le soupçonne fortement. Tous les While présents ne sont là que pour effectuer un parcours ou atteindre une donnée dans une table (c'est là qu'une bdd relationnelle aurait été cool....), je pense que je vais donc devoir passer par un dataSet dans ce genre de situation. Qu'en pensez-vous ?

  19. #19
    Membre éprouvé
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    948
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 948
    Points : 1 111
    Points
    1 111
    Par défaut
    Si tu utilises déjà le profiler et que tu ne vois rien de louche de ce coté là, je ne sais pas trop. J'avoue que le script que tu donnes en exemple, je n'y comprends absolument rien

    Je suis en revanche curieux, qu'est ce qui te fait penser que ca ira plus vite avec un dataset? (ce n'est pas pour te décourager de le faire, simplement je ne comprends pas ce qui serait plus rapide dans le dataset?)

  20. #20
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 177
    Points : 25 122
    Points
    25 122
    Par défaut
    souvent les traitements longs et mals codés c'est

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    parcours d'un datareader
      execution d'une requete concaténée avec une valeur du datareader externe
    fin boucle
    ce qui fait des milliers de requete au lieu d'une avec une jointure

Discussions similaires

  1. Réponses: 8
    Dernier message: 23/06/2011, 20h19
  2. Réponses: 11
    Dernier message: 28/02/2008, 16h39
  3. Réponses: 2
    Dernier message: 08/01/2008, 06h07
  4. Réponses: 4
    Dernier message: 11/05/2006, 16h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo