Quel est le point de DBNull?

Dans .NET il y a le null de référence, qui est utilisé partout pour indiquer qu'un objet de référence est vide, et puis il y a la DBNull, qui est utilisé par les pilotes de base de données (et quelques autres) pour désigner... à peu près la même chose. Naturellement, cela crée beaucoup de confusion et de routines de conversion doivent être sortis, etc.

Alors, pourquoi l'original .NET les auteurs décident de faire cela? Pour moi, il n'a pas de sens. Leur documentation n'a pas de sens, soit:

La DBNull classe représente une inexistant valeur. Dans une base de données, par exemple, une colonne dans une ligne d'une table peut ne pas contenir toutes sortes de données que ce soit. Qui est, la colonne est considérée ne pas exister du tout, au lieu de se contenter de ne pas avoir une valeur. Un DBNull objet représente l'inexistante de la colonne. En outre, l'interopérabilité COM utilise le DBNull classe de distinguer entre une VT_NULL variante, ce qui indique une inexistant valeur, et un VT_EMPTY variante, ce qui indique une valeur quelconque.

C'est quoi cette merde sur une colonne "n'existant pas"? Il existe une colonne, il n'a tout simplement pas avoir une valeur pour la ligne particulière. Si elle n'existait pas, j'aurais une exception en essayant d'accéder à la cellule spécifique, pas une DBNull! Je peux comprendre la nécessité de faire la distinction entre VT_NULL et VT_EMPTY, mais alors pourquoi ne pas faire un COMEmpty classe à la place? Ce serait beaucoup plus lisible ajustement dans l'ensemble .NET framework.

Suis-je raté quelque chose? Quelqu'un peut-il éclairer pourquoi DBNull a été inventé, et les problèmes qu'il aide à résoudre?

  • Juste un autre point de données... DBI (Interface de Base de données) module dans le langage Perl n'ont pas un concept de DbNull. Lorsqu'une valeur est NULL dans la base de données, DBI représente comme le Perl "undef" qui est le Perl équivalent de "null" en C#. Si Perl a pris la position d'un "DbNull" concept n'est pas nécessaire et je n'ai pas entendu de tous les programmeurs Perl souhaitant qu'ils avaient DbNull.
  • Je suis avec vous, @JoelFan - je ne vois pas de réel intérêt dans il soit
  • Outre les réponses ci-dessous, le commentaire ci-dessous par @thomas-levesque est très important: DBNull est antérieure à l'introduction dans le .NET framework de véritables types nullables. Tant leur comportement est légèrement différent, donc DBNull avait de séjour (à mon grand regret, mais c'est une autre histoire).
  • J'aime la question, mais je dois dire que la communauté est incohérent. Beaucoup de questions sur "pourquoi est-il de cette façon?" obtenir fermés que "pas question", surtout si la personne se permet d'expliquer pourquoi quelque chose semble n'avoir aucun sens. (J'ai essayé de demander ou se plaindre du manque de soutien approprié pour les types abstraits en exposant des services WCF en tant que services web et me suis tourné vers le bas tout de suite!)
InformationsquelleAutor Vilx- | 2010-12-20
  1. 45

    Le point est que, dans certaines situations, il y a une différence entre une base de données de la valeur null, et une .NET Null.

    Par exemple. Si vous utilisez ExecuteScalar (qui renvoie à la première colonne de la première ligne du jeu de résultats) et vous obtenez une valeur null dos qui signifie que le SQL exécutées n'ont pas de retour de toutes les valeurs. Si vous obtenez DBNull de retour, il signifie une valeur a été renvoyée par le SQL et il était NULL. Vous devez être en mesure de faire la différence.

    • Bon, c'est un bon exemple, je suppose. Si pas assez de raison pour justifier de tout ce gâchis. ExecuteScalar pourrait avoir été réécrit différemment pour résoudre ce problème particulier (DBEmptyRowset, anyone?)
    • Je suis heureux avec la façon dont Microsoft a écrit ADO.NET. L'utilisation de DBNull garde tout cohérent. Tout moment une valeur de colonne est null, vous obtenez un DBNull. Vous assurer que le code de poignée qui peut être un peu plus lourd qu'un simple null retourner, surtout si tout ce que vous faire est de convertir DBNull à null, mais à la fin de la journée, la cohérence est la clé. Si ils avaient varié ExecuteScalar parce que vous avez besoin de faire la différence dans ce scénario, il aurait pot beaucoup plus. Bien sûr, c'est juste mon avis.
    • Variables d'un ExecuteScalar() méthode vs varient tout le DB, des fournisseurs, des ensembles de données/Tables/Lignes/Colonnes, des contrôles liés aux données, et quoi d'autre pas? J'irais pour la première. À la fin de la journée, pour que le code BEAUCOUP plus cohérente. Et simple. Outre - ExecuteScalar est l'un des moins les méthodes utilisées dans les fournisseurs de données. >90% des cas sont avec DataReader. Plus - pensez-vous vraiment qu'un bool ExecuteScalar(out object Value) serait que incohérent?
    • OK, j'ai supprimé le mien aussi. 🙂 De toute façon, je ne pense pas que vous avez besoin de s'inquiéter. DBNull et de la vieille Api sont là pour rester - trop de code s'appuie sur elle. 🙂
    • vous pensez vraiment qu'un bool ExecuteScalar(hors objets de Valeur), serait que incohérent?" Non, mais il a aussi des bocaux. Quoi que ce soit avec un out paramètre pots. Mais là encore, C# ne gère pas les Tuples bien (un peu d'une omission de la langue, je pense)
    • Ahh, les vieilles rancunes. 🙂 Le bool/out est cohérent avec les dictionnaires, c'est pourquoi je l'ai choisi à l'origine. Alternativement, il pourrait juste retour d'un object, puis créez une valeur spéciale pour un ensemble de lignes vide, par opposition à une valeur spéciale pour une valeur vide. Ou peut-être retourner la valeur null, et ont une option de out bool paramètre, car dans la plupart des cas, vous n'avez pas vraiment sur le vide-ensemble de lignes de cas.
    • Même si ça contredit le nom de la méthode, ExecuteScalar pourrait également retourner une IEnumerable<object> avec un ou des valeurs nulles.
    • Ils pourraient venons de rentrer d'un ScalarResult avec un HasValue et Value de la propriété. Il n'y a aucune raison valable pour beaucoup d'autres méthodes de retour DBNull au lieu de null. C'est juste une mauvaise conception.
    • Il y a beaucoup de choses qu'ils pouvaient faire. Mais ce qui est fait est fait et Microsoft ont pour le soutenir, pour s'assurer que toutes les applications que l'ont ne se cassent pas.
    • Personnellement, j'aurais préféré ExecuteScalar lever une exception (DbException) si il n'y avait pas une valeur de retour (pas de lignes, ou pas de colonnes), et utilisé null au lieu de DBNull
    • Bon point que vous avez dit dans votre réponse. mais n'est-ce pas la principale différence entre DBNULL et .NET null; DBNULL Disque dur est NULL .NET, la valeur null est la Mémoire NULL. Depuis le disque dur Alloue un espace pour un dossier même si il n'y a rien, mais la mémoire n'a pas allouer de l'espace pour de pointeur null car il ne fait pas référence tas adresse;
    • Je ne comprends pas ce que tu veux dire - à la Fois la mémoire et le disque dur sont des supports de stockage (quoique plus éphémère que les autres) dans ce sens, il n'y a pas de différence. Si la ligne existe alors une valeur pour une colonne de la rangée peut retourner DBNULL pour indiquer que la colonne de cette ligne n'a aucune valeur. Pour ExecuteScalar NULL signifie que pas de lignes ont été retournés, et DBNULL est qu'au moins une ligne a été retourné, mais la première colonne n'a pas de valeur.

    InformationsquelleAutor Colin Mackay
  2. 167

    Je ne suis pas daccord avec la tendance ici. Je vais aller sur le dossier:

    Je ne suis pas d'accord que DBNull sert aucune fin utile; il s'y ajoute une confusion inutile, tout en contribuant pratiquement aucune valeur.

    L'argument est souvent mis en avant que les null est une référence non valide, et que DBNull est un objet nul motif; n'est pas vraie,. Par exemple:

    int? x = null;

    ce n'est pas une référence non valide"; c'est une null valeur. En effet null signifie tout ce que vous voulez dire, et franchement, je n'ai absolument aucun problème à travailler avec des valeurs qui peuvent être null (en effet, même dans SQL nous avons besoin pour travailler correctement avec null - rien ne change ici). De même, la "objet nul motif" n'a de sens que si vous êtes réellement en la traitant comme un objet en programmation orientée objet, mais si nous avons une valeur qui peut être "notre valeur, ou un DBNull" ensuite, il doit être object, donc on ne peut pas être quelque chose d'utile avec elle.

    Il y a beaucoup de mauvaises choses avec DBNull:

    • il vous oblige à travailler avec object, puisque seulement object peut contenir DBNull ou une autre valeur
    • il n'y a pas de réelle différence entre "pourrait être une valeur ou DBNull" vs "pourrait être une valeur ou null"
    • l'argument qu'elle découle d'1.1 (pré-nullable-types) est vide de sens; nous pourrions utiliser null parfaitement bien dans 1.1
    • la plupart des Api ont "est-il nul?" méthodes, par exemple DBDataReader.IsDBNull ou DataRow.IsNull - ni réellement besoin DBNull existe sur le plan de l'API
    • DBNull échoue en termes de null-coalescence; value ?? defaultValue ne fonctionne pas si la valeur est DBNull
    • DBNull.Value ne peut pas être utilisé dans les paramètres facultatifs, car ce n'est pas une constante
    • l'exécution de la sémantique de DBNull sont identiques à la sémantique de null; en particulier, DBNull fait est égal à DBNull - il ne pas faire le travail de représentation de la sémantique SQL
    • souvent les forces de la valeur des valeurs du type à être mis en boîte car il utilise object
    • si vous avez besoin de tester pour DBNull, vous pourriez aussi bien avoir testé juste pour null
    • il provoque d'énormes problèmes pour des choses comme la commande des paramètres, avec un comportement idiot que si un paramètre a une null valeur, il n'est pas envoyé... eh bien, en voilà une idée: si vous ne voulez pas un paramètre envoyé - ne pas l'ajouter à la collection de paramètres
    • tous les ORM je pense, fonctionne parfaitement bien sans tout besoin ou de l'utilisation de DBNull, sauf comme un supplément de nuisance lorsque l'on parle à l'ADO.NET code

    La seule même à distance argument convaincant j'ai jamais vu pour justifier la existence d'une telle valeur est en DataTable, lors du passage en valeurs afin de créer une nouvelle ligne; un null signifie "utiliser par défaut", un DBNull est explicitement null franchement cette API pourrait avoir eu un traitement spécifique pour ce cas - imaginaire DataRow.DefaultValue par exemple serait beaucoup mieux que de l'introduction d'un DBNull.Value qui infecte de vastes portions de code pour aucune raison.

    De même, la ExecuteScalar scénario est... au mieux précaire; si vous exécutez un scalaire méthode, vous attendre un résultat. Dans le scénario où il n'y a pas de lignes, de retour null ne semble pas trop terrible. Si vous avez absolument besoin de lever l'ambiguïté entre "pas de lignes" et "une seule valeur null est retournée", il y a le lecteur de l'API.

    Ce navire a navigué il y a longtemps, et il est beaucoup trop tard pour le corriger. Mais! S'il vous plaît ne pas pense que tout le monde est d'accord que c'est une "évidence" de la chose. Beaucoup de développeurs ne pas voir de la valeur dans ce drôle de pli sur la BCL.

    En fait je me demande si tout cela provient de deux choses:

    • avoir à utiliser le mot Nothing au lieu de quelque chose avec la valeur "null" dans VB
    • être en mesure de nous le if(value is DBNull) syntaxe qui "ressemble à SQL", plutôt que de oh-so-tricky if(value==null)

    Résumé:

    Avoir 3 options (null, DBNull, ou une valeur réelle) n'est utile que s'il existe un véritable exemple où vous avez besoin de lever l'ambiguïté entre les 3 cas différents. Je n'ai pas encore vu une occasion où j'ai besoin de représenter les deux "null" les états, de sorte DBNull est entièrement redondant étant donné que null existe déjà et a beaucoup mieux la langue et à l'exécution.

    • +1, je n'ai jamais eu une situation où je voulais DBNull.La valeur doit être différencié de la valeur null. J'ai toujours estimé que c'était mal, et vu (+ connu) beaucoup de temps perdu en raison du fait nul != DBNull.Valeur
    • Est-il une faute de frappe à "DBNull fait est égal à DBNull", si ce n'est pas que je ne comprends pas :). Ne devrait-elle pas être "DBNull fait est égal à null"?
    • non, pas de faute de frappe; et DBNull certainement n'est pas égal à null; try bool x = DBNull.Value.Equals(DBNull.Value); bool y = DBNull.Value.Equals(null);. Le point que j'essayais de faire ici est que si vous essayez de faire cela dans un conforme à la norme ANSI SQL base de données, vous trouverez que null n'est pas égale à null (mais en même temps, null ne "pas égal" null)
    • Merci pour le heads up, je me demandais juste si il y a un cas où DBNull n'est PAS DBNull (Dans le contexte de ADO.NET). M'a un peu confus.
    • (déplacé à partir de stackoverflow.com/questions/4958379/..., par la voie semblait un meilleur ajustement)
    • +1 en Effet la situation avec DBNull aurait pu être beaucoup mieux.
    • Je pense que le Nothing dans VB.Net est proche de la marque. Vb.Net's Nothing n'est pas un équivalent direct de C#'s null (c'est plus près de match pour default(T)) et, par conséquent, ne peut pas remplir pour VB.Net chaque fonction que vous suggérez null permettrait de mieux accomplir vs DBNull.Valeur en C#. Mais, oui: DBNull.Valeur suce. J'aimerais voir l'équipe CLR mettre en œuvre une sorte de "conversion automatique", donc si vous passez null ado.net méthodes de l'api, où seule DBNull.La valeur est valide (ou le définir comme la valeur d'un paramètre, par exemple), il fait la conversion pour vous.
    • Un upvote de moi! C'est ce que j'ai dit tout au long de! 🙂
    • Je trouve ton texte vraiment déroutant lorsque vous continuez à parler de "valeurs null' (a null jamais été une valeur? Mon cerveau n'arrête pas de dire non ...) et DBNull des "valeurs": DBNull est un type de données. Donc écrire qu'un objet peut contenir une valeur DBNull est totalement incompréhensibles pour moi!
    • une variable a une valeur. La valeur d'une variable peut être "null" (pour la référence-types, y compris object, et pour les valeurs null--de-T). Oui, la valeur null est une valeur. Dans le cas de référence de type de variables, il est le tout-zéro de référence (bien que techniquement faible valeur non nulle références seront également interprétées comme nulle dans certains scénarios, en raison d'un détail de l'implémentation). Un object variable peut contenir une référence à une instance de DBNull; ce dernier, peut-être, je n'ai abréger - mais je ne pense pas que le sens est perdu.
    • merci pour votre réponse. Dans mon idée (et je pense que c'est assez courant quand on parle des maths), la notion de valeur n'existe pas en dehors du concept de base de comparaison. Comme les valeurs null ne peut pas être comparé, ni ils peuvent être commandés, ajoutée, etc, ils ne peuvent pas être appelés des "valeurs". En fait, la valeur Null est une représentation d'une absence de valeur. Cela dit, ce concept n'est pas rigoureusement mis en œuvre dans les langages informatiques, où les approximations comme (comparaison)"si my_x = null" ou (affectation)"x = null" sont communs. Donc, on pourrait dire que, quand il s'agit de l'informatique, la valeur null est une valeur ... mais je ne l'aime pas!
    • Je parle de la programmation, de sorte que la valeur "null" est tout simplement la séquence de bits qui représente le concept de nul, qui, d'ailleurs, dans le contexte de l'objet est tout simplement "sans objet". Le terme "null" est surchargé, et ce n'est pas les maths utilisation. Bien en fait le concept si nul ne fait pas les trouver dans la majorité des mathématiques.
    • <3 cette réponse. C'est exactement ce que je pense et dis que si j'ai passé un moment à penser et dire ceci.
    • Se pourrait-il que DBNull a été introduit à avoir un type CLR avec le même sémantique en tant que base de données des valeurs null? Rappelons que la valeur null est inégale à quoi que ce soit, y compris null, bases de données relationnelles, de sorte que, par exemple, de choisir quelque chose où Col1 = Col2 n'a pas de match où les deux colonnes "n'ont aucune valeur". La valeur Null est en effet censé représenter "aucune valeur", de ne pas servir de "magie de la valeur". Pour parler de ce qui séquence de bits est utilisé pour représenter le concept de "ne pas avoir une valeur" est complètement à côté de la question.
    • Je commente que: si c'est l'intention qu'il échoue, comme expliqué dans ma réponse
    • Je vois maintenant que vous l'avez fait, sur la sémantique. Mais le deuxième point de stands (paramètres avec des valeurs par défaut). Ici, nous avons une situation où il peut être "ma valeur" ou DBNull ou CLR null, le dernier sens "utiliser la valeur par défaut". Bien sûr, ce dernier pourrait être obtenue par d'autres moyens (par exemple, l'omission du paramètre), mais je ne pense pas que ce serait logique. Ne pas dire DBNull est une bonne chose; je ne suis pas persuadé que c'est une mauvaise chose.
    • Vérifier IsDBNull est juste quelque chose que je suis venu à accepter. Une jointure externe peut produire une absence de valeur. Peut-être certains d'optimisation de ne pas produire une valeur null. Je suis probablement donner Lecteur trop de crédit, mais il peut être plus efficace, de retour d'un IsDBNull que de retourner une valeur null.
    • non, il n'est pas plus efficace d'utiliser un dbnull plutôt que null. Et oui, certaines jointures etc quitter l'absence de données - null: mais ce n'est pas dicter null vs dbnull
    • Il n'a pas de sens d'affirmer que DBNull est redondante avec null parce que null, c'est le mal et un défaut de conception. Accordé, être forcé d'utiliser object est également un défaut de conception, mais il est inexact de dire que seuls les object pourrait tenir DBNull ou une autre valeur un type somme ferait l'affaire.
    • Il est possible d'éviter deux de vos points de douleur, 1: être obligé de travailler avec object et 2: après avoir brisé null-coalescence en échange de l'utilisation de la System.Data.SqlTypes espace de noms. Ce n'est pas l'idéal (je préfère utiliser le construit en types), mais il fonctionne. Par exemple, int? example = null;SqlInt32 nocast = example ?? SqlInt32.Null; à Partir d'un code de rédaction de point de vue, ce n'est pas vraiment beaucoup d'une victoire, mais au moins il est facile à lire.
    • oui, mais le problème est de les corriger à la fois avec le même code. L'un de ces "corrections" est mutuellement exclusive avec les autres.
    • ah, j'ai mal lu ce que vous disiez. Le problème puis, c'est que vous êtes maintenant à l'aide d' SqlClient - qui je déconseille fortement dans le cas général. Il y a beaucoup, beaucoup de bonnes raisons pour utiliser nue ADO.NET types (non spécifique au fournisseur types) dans la mesure du possible.

    InformationsquelleAutor Marc Gravell
  3. 13

    DbNull représente une zone avec pas de contenu; null indique la non-existence de la boîte.

    • Vraiment? Soins pour revenir sur ce point? J'ai un peu de ne pas l'obtenir. En particulier, depuis une variable ("la boîte") ne disparaît pas lorsque vous affectez une null à elle.
    • Si l'on considère la variable à l'adresse de la boîte, puis lorsque vous affectez une valeur null à une variable, vous indiquez à la variable que la boîte n'existe plus. Qui est, l'adresse n'est pas "visitables'.
    • Je suis d'accord que la documentation est simplement faux sur la colonne n'existe pas.
    • Dans la mesure où la documentation est faux, je soupçonne qu'il a été mal écrit plutôt que de malencontreuses.
    • CRÉER PROC [Echo] @s de type varchar(max) = 'bonjour' SELECT @s [Echo]. SqlCommand cmd = new SqlCommand("Echo"); cmd.Les paramètres.AddWithValue("@s", null); l'Exécution de la commande et regardez le résultat (il utilisera le paramètre de defualt valeur). Maintenant, changez la valeur du paramètre DBNull.La valeur de la proc fera l'écho de la valeur fournie, la valeur NULL. Il y a un semantical différence entre DBNull et null. Vous pourriez obtenir le même en modifiant les paramètres, mais ici, la même commande peut être utilisé de nombreuses fois, en changeant uniquement les valeurs de paramètre - ce qui est considérablement plus rapide.
    • Je ne pense pas que cette fonctionnalité est en valeur la dispute de la vérification et de la conversion à la fois nulle et dbnull lors de l'utilisation de nullable objets.

    InformationsquelleAutor Rikalous
  4. 1

    Vous utilisez DBNull pour les données manquantes. La valeur Null dans la .NET langue signifie qu'il n'y a pas de pointeur d'un objet/variable.

    DBNull données manquantes: http://msdn.microsoft.com/en-us/library/system.dbnull.value.aspx

    Les effets de l'absence de données sur les statistiques:

    http://en.wikipedia.org/wiki/Missing_values

    • Qu'en est Nullable<int> alors? C'est un type de valeur, pas de pointeurs. C'est peut-être une erreur alors?
    • Et aussi - ce qui reste est un "pas de pointeur d'un objet" si pas de données manquantes?
    • les types nullables n'existait pas dans .NET 1.0/1.1, donc une autre manière de représenter les valeurs null est nécessaire
    • Levesque - votre commentaire est digne d'être une réponse, je dirais. Bien qu'il n'explique toujours pas pourquoi un simple "null" ne pouvait pas avoir été utilisé tout aussi bien. Pour créer une variable qui pourrait détenir à la fois un type de valeur et DBNull, vous auriez à en faire un Système.Objet" de toute façon.
    • cette logique ne fonctionne pas; pour stocker une valeur ou DBNull" nous avons besoin d'utiliser object - c'est toujours le cas dans la version 2.0+; object pouvez stocker null parfaitement bien donc, même lors de l'utilisation de object, le DBNull.Value est toujours redondant
    InformationsquelleAutor jvdbogae
  5. 0

    Il y a quelques différences entre un CLR nulle et une DBNull. Tout d'abord, la valeur null dans les bases de données relationnelles a différents "équivaut à" la sémantique: null n'est pas égal à null. CLR null EST égal à null.

    Mais je soupçonne que la raison principale est la façon par laquelle le paramètre valeurs par défaut dans SQL server et la mise en œuvre du fournisseur.

    Pour voir la différence, créer une procédure avec un paramètre qui a une valeur par défaut:

    CREATE PROC [Echo] @s varchar(MAX) = 'hello'
AS
    SELECT @s [Echo]

    Bien structuré DAL code qui doit séparer de création de commande de l'utilisation (pour permettre à l'aide de la même commande plusieurs fois, par exemple pour appeler une procédure stockée à de nombreuses reprises de manière efficace). Écrire une méthode qui retourne un SqlCommand représentant la procédure ci-dessus:

    SqlCommand GetEchoProc()
{
    var cmd = new SqlCommand("Echo");
    cmd.Parameters.Add("@s", SqlDbType.VarChar);
    return cmd;
}

    Maintenant, si vous invoquez la commande sans paramètre de la @s paramètre, ou de définir sa valeur (CLR) est null, il utilisera par défaut la valeur "bonjour". En revanche, si vous définissez la valeur du paramètre DBNull.Valeur, il sera utilisé et de l'écho DbNull.Valeur.

    Puisqu'il y a deux résultats différents à l'aide de CLR null ou à la base de la valeur null comme valeur de paramètre, vous ne pouvez pas représenter les deux cas avec un seul d'entre eux. Si CLR null devait être le seul, qu'il faudrait travailler à la manière dont DBNull.Valeur d'aujourd'hui. Un moyen d'indiquer au fournisseur "je veux utiliser la valeur par défaut" pourrait alors être de ne pas déclarer le paramètre (un paramètre avec une valeur par défaut bien sûr de sens que pour décrire comme un "paramètre facultatif"), mais dans un scénario où la commande objet est mis en cache et réutilisés, ce qui a suscité la suppression et re-ajout du paramètre.

    Je ne suis pas sûr si je pense que DBNull était une bonne idée ou pas, mais beaucoup de gens ne sont pas conscients des choses que j'ai mentionnées ici, donc j'ai pensé qu'il vaut la peine de mentionner.

    • J'ai appris quelque chose: DBNull n'a pas en fait l'égal de la sémantique de la base de données les valeurs null. Le deuxième point tient toujours, si - DBNull ou null vraiment fonctionnent différemment que les valeurs de paramètre.
    • Je pense que c'est la croyance commune que la DBNull et nulle divergence existait à l'origine parce que .NET et SQL Server a été construit à l'origine par des équipes distinctes. On peut se demander si les deux valeurs null existent aujourd'hui comme un héritage de cette distinct des équipes, ou comme quelque chose qui bénéficie de plus de gêne.
    InformationsquelleAutor The Dag