Comment gérer une conversion DBNull en booléenne dans mon ensemble de données XSD?

Question

Dans ma base de données, quelques colonnes de l'une de mes tables sont des valeurs en bits (booléens). Ils sont autorisés à être NULL car les champs ne vont pas toujours contenir des données.

J'ai créé le jeu de données XSD à l'aide de la table et vérifié que le champ AllowDBNull est défini sur True.

Cependant, lorsque je récupère un enregistrement vers le bas de la base de données dans le datatable à l'aide de la méthode GetData configurée, je rencontre l'erreur suivante:

[InvalidCastException: Conversion from type 'DBNull' to type 'Boolean' is not valid.]

Dois-je spécifier quelque chose d'autre que le champ Valeur par défaut de la colonne ou y a-t-il un autre champ à définir?

Je suis toujours en phase de développement avec ce projet. Par conséquent, si vous préférez remplacer les champs par un caractère et utiliser l'option O / N / NULL, vous ne risquez pas trop de le faire.

Answer 1

IMHO, vous ne devriez pas autoriser les NULL dans un champ bit / boolean.

Mike Hadlow a un bon post à ce sujet ici:

http://mikehadlow.blogspot.com/2006/10/nullability -voodoo.html

Booléen est par définition un type à deux états. En le rendant Nullable, vous ajoutez un troisième état. Il reviendra vous hanter à un moment donné.

Answer 2

Je ne suis pas d'accord avec Iain. La logique à trois valeurs est aussi viable que la logique à deux valeurs. La personne à la table est vivante ou morte ou vous ne savez pas s'il est vivant ou mort. Si Mike avait son chemin, vous ne pourriez pas en utiliser un peu ici. Vous auriez besoin d'un FK pour une table d'état, 1 = Alive, 2 = Dead, 3 = Unknown.

Le but du bit est de gagner de la place, vous pouvez toujours transformer la colonne en CHAR (1) avec une contrainte limitant les valeurs à T ou F, Y ou N (ou U).

Mais je pense que Iain interprète mal ce que dit Mike. Mike ne décourage pas l'utilisation de Nulls, après tout, il pense que la colonne EndDate devrait être nulle jusqu'à ce que le processus soit terminé. Il dit juste que ne donnez pas de propriétés mystiques à une valeur nulle dans la colonne ... comme si c'était la clé pour savoir si un processus se trouvait dans un certain état.

En fait, les nulls dans une base de données ont certains effets secondaires très utiles. Oracle (peut-être d'autres bases de données) n'indexe pas les valeurs NULL. Donc, si vous avez une colonne dans laquelle une seule valeur est importante - comme, par exemple, vous avez une liste d'employés que vous ne purgez jamais et une colonne de bits Is_Active_Employee indexée. Dans ce cas, pour une entreprise établie, le nombre d'employés que vous avez eu est de > > > que le nombre d'employés que vous avez maintenant. Supposons que vous avez 1% 1 et 99% 0.

Cet index est 99 fois plus grand que nécessaire. Il s'agit d'indexer tous les 1, ce qui est bien, car ils représentent 1% de la table, mais ils sont également chargés de 0 pour les lignes que vous ne pourriez jamais utiliser pour trouver cet index. Si vous voulez que tous les employés inactifs, l'indexé serait ignoré et un FTS serait exécuté. Donc, 1 et NULL seraient BEAUCOUP plus efficaces du point de vue des bases de données.