Traitement des valeurs nulles par rapport aux chaînes vides dans une base de données lorsque seules les chaînes vides proviennent du client via HTTP POST

Question

Ma base de données MySQL contient des champs soigneusement définis. Certains champs, s'il y a une chance qu'ils puissent être inconnus, autorisent une valeur NULL.

J'écris un CMS basé sur le Web pour gérer les données dans cette base de données. Évidemment, les tableaux de messages des formulaires HTML ne contiennent jamais de valeurs nulles, seulement des chaînes vides. Je ne veux pas confondre les utilisateurs de mon CMS en ajoutant une "case à cocher NULL" ou quelque chose comme ça, mais je ne peux pas dire à partir des tableaux de post si un champ doit être vide ou vide.

Dois-je convertir toutes les chaînes vides en valeurs NULL lors de la sauvegarde pour les champs qui autorisent les valeurs NULL?

Quelles sont les bonnes pratiques pour ce type d'énigme?

Answer 1

C'est une question délicate. Bien sûr, il n'y a aucun moyen pour un utilisateur de savoir s'il veut insérer une chaîne vide ou rien du tout. Donc, la réponse est vraiment à vous. Voulez-vous autoriser les utilisateurs à entrer des chaînes vides? Cela a-t-il une signification pour le faire? Si une chaîne vide signifie quelque chose qu'une chaîne NULL n'a pas et qui est bien défini, allez-y et laissez les deux.

S'il n'y a pas de distinction entre eux, choisissez-en un et respectez-le. Personnellement, je ne vois pas pourquoi vous devriez garder des chaînes vides comme ça, ça rend les choses beaucoup plus confuses plus tard. Il suffit de coller avec NULL pour représenter une absence de données. Prenez votre décision maintenant, documentez-la et respectez-la.

Answer 2

Voulez-vous vraiment faire face à la véritable NULL, avec son three-value logic difficile?

Dans mon expérience, vous voulez rarement l'incertitude explicite qui vient avec NULL. Stocker une chaîne vide pour des valeurs que l'utilisateur n'a pas besoin de remplir est généralement plus pratique. Ensuite, vous pouvez aller de l'avant et faire des recherches comme WHERE t.field<>'x' ou WHERE t0.field=t1.field sans avoir à vous soucier de ce que cela fait à votre logique booléenne lorsque l'un ou les deux sont nuls.

Si vous avez déjà une base de données de travail qui repose sur la nature incertaine de null, et c'est une partie intrinsèque de vos besoins, alors bien, restez avec null (et dans ce cas vous devrez probablement convertir vide entrée de l'utilisateur dans un champ nullable à null juste parce qu'aucun utilisateur final est jamais va être en mesure de comprendre la différence conceptuelle entre rien et null).

Mais personnellement, je n'utilise toujours que des valeurs NULL pour les références de clés étrangères facultatives (si vous n'utilisez pas de table de jointure séparée).