Dois-je stocker False comme Null dans un champ de base de données booléenne?

20

Disons que vous avez une application qui a un champ booléen dans sa Usertable appelé Inactive.

Y a-t-il quelque chose de fondamentalement mauvais à simplement stocker false comme nul? Si oui, pouvez-vous s'il vous plaît expliquer quel devrait être le côté négatif? J'ai discuté de cela avec quelqu'un il y a quelques mois et nous avons tous deux convenu que cela ne devrait pas avoir d'importance tant que vous le faites de manière cohérente dans l'application / la base de données. Récemment, quelqu'un que je connais a insisté sur le fait que "vrai" trueou falsedevrait être utilisé, mais ils n'ont pas vraiment expliqué pourquoi.

database-design null

— Ominus
source

25

Wikipedia dit que

Null is a special marker used in Structured Query Language (SQL) to indicate that a data value does not exist in the database

c'est la sagesse acceptée et vous ne devriez pas redéfinir ce que signifie Null dans votre application. Ce sera déroutant pour tous les autres utilisateurs de votre code.

— PersonalNexus

10

Pourquoi voudriez-vous même faire cela? Pourquoi ne pas simplement utiliser un champ de bits non nullable et définir la valeur par défaut sur false si tel est le comportement que vous souhaitez au lieu de confondre le problème avec un champ à trois états?

— JohnFx

5

Exemple concret de pourquoi c'est une très mauvaise idée: SELECT * FROM foo WHERE bar = FALSEne donne pas les résultats que vous attendez.

— Blrfl

2

Pensez à utiliser une colonne int avec une valeur par défaut de 0 plutôt que booléenne. De cette façon, si de nouvelles conditions surviennent (peut-être un état «en attente», par exemple), vous n'avez pas à modifier la structure de la base de données.

— GrandmasterB

4

Mais si vous stockez false comme null, comment allez-vous stocker FILE_NOT_FOUND?! ( thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )

— Ed James

50

Y a-t-il quelque chose d'intrinsèquement mauvais à simplement stocker false comme nul?

Oui.

Dans l'affirmative, pouvez-vous expliquer ce que devrait être l'inconvénient?

NULL n'est pas identique à False.

Par définition, les comparaisons (et la logique) qui impliquent NULL doivent renvoyer des valeurs de NULL (pas False). Cependant, les implémentations SQL peuvent varier.

True and NULL est NULL (pas False).

True and NULL or False est NULL (pas False).

http://en.wikipedia.org/wiki/Null_(SQL)#Three-valued_logic_.283VL.29

http://technet.microsoft.com/en-us/library/cc966426.aspx

— S.Lott
source

3

Explication succincte sur pourquoi NULL est la valeur représentant l'absence de valeur.

— maple_shaft

2

le premier jour de mon premier travail de développement a impliqué le débogage et la correction d'une erreur comme dans cette question / réponse, réminiscence +1

— tsundoku

1

Notez que l'article auquel vous avez lié dit que si le nulln'est pas pertinent pour la logique (comme c'est le cas dans whatever OR TRUEou whatever AND FALSE, où aucune valeur de whateverne peut changer la condition), alors l'expression renvoie une valeur. Ce n'est pas une optimisation; c'est ainsi que fonctionne la logique à 3 valeurs . Tout SGBD qui insiste pour retourner UNKNOWN/ NULLpour ces expressions est fondamentalement cassé.

— cHao

1

@ S.Lott, mais ne stocke pas null au lieu de false, économise de l'espace ??

— azerafati

2

@Bludream: Pour les booléens, un champ nullable peut en fait prendre plus d' espace, selon le SGBD. (C'est un montant négligeable dans presque tous les cas, cependant.) Un booléen peut être représenté dans un seul bit ... mais un booléen nullable a trois valeurs possibles (true, false et null), et a donc besoin de plus d'un bit.

— cHao

15

En autorisant les valeurs nulles dans un champ booléen, vous transformez une représentation binaire voulue (vrai / faux) en une représentation à trois états (vrai, faux, nul) où vos entrées «nulles» sont indéterminées. La valeur «nulle» n'est ni «vrai» ni «faux». Quelle raison auriez-vous à augmenter votre représentation pour être inexacte?

Même si vous décidez d'un modèle comme celui-ci et que vous le faites de manière cohérente tout au long de votre application, cela ne vous convient pas. Vous vous retrouverez dans une situation où il n'est pas clair pour les yeux frais pourquoi ce modèle est en place ou, plus probablement, vous vous retrouverez dans une situation où ce modèle est accidentellement cassé.

— Jacob Maristany
source

5

Ce que les autres ont dit. 3 valeurs possibles n'est pas un booléen.

Mais vous pouvez avoir un besoin légitime de 3 valeurs. Tels que (vrai, faux, inconnu). Même si c'est le cas, si vous êtes dans l'ultra-normalisation, vous n'accepterez aucune valeur nulle. Au lieu de cela, vous stockerez un vrai booléen dans une autre table avec une relation 1 à 1. Une valeur nulle peut être produite dans une requête par une jointure externe "ayant échoué", et non par une valeur nulle stockée physiquement.

— Lord Tydus
source

en dehors du domaine de ma question booléenne, pourquoi le vrai faux inconnu serait-il mauvais si vous utilisiez null pour le faire? Au-delà de ma question, les null sont-ils généralement à éviter? Pourquoi?

— Ominus

3

@Ominus: Les nuls sont généralement à éviter si vous êtes un puriste. S'ils sont utilisés tels qu'ils étaient censés être utilisés (comme "il n'y a pas de valeur ici" plutôt que comme faux-faux false), alors ils ont leur place. S'ils ne le faisaient pas, ils n'existeraient pas. L'alternative, comme mentionné, est essentiellement d'avoir une toute autre table avec juste la clé primaire de votre ligne et un seul booléen (ou int, ou varchar, ou ce que vous avez). Pour chaque champ que vous auriez autrement rendu nullable. Relativement pur, il est trop alambiqué pour la plupart des usages.

— cHao

-3

Est-ce bool?un type booléen? Non. C'est du type Nullable<T>où Test booléen. Un booléen nullable peut avoir 3 valeurs: true, false et null. À utiliser boolou bool?dépend de vos besoins. Il peut y avoir une raison légitime pour laquelle vous devrez peut-être utiliser null mais un type qui sent binaire mais vous ne connaissez pas la réponse. Dans l'exemple ci-dessus,User.IsActivesemble clair. L'utilisateur est actif ou non. En tant que système, il peut vouloir savoir si un utilisateur est actif ou non. Il ne devrait pas y avoir «peut-être». Mais pensez à quelque chose comme un indicateur de fonctionnalité. La fonction est-elle activée? Les réponses pourraient être oui, non ou incertaines. Vous pouvez avoir une règle métier qui indique clairement que le bouton n'est affiché que lorsque l'indicateur est défini sur true. On peut soutenir que bool est faux par défaut, alors pourquoi créer un bool nullable? Inversez l'exigence: allez-vous définir toutes les valeurs de la source de données sur true?

— nullableTypes
source

2

ce post est assez difficile à lire (mur de texte). Pourriez-vous le modifier sous une meilleure forme?

— moucher