NULL vs vide lorsqu'il s'agit d'une entrée utilisateur
Oui, un autre NULL vs chaîne vide en question.
je suis d'accord avec l'idée que NULL signifie non défini, tandis que la chaîne vide signifie"une valeur qui est vide". Voici mon problème: si la valeur par défaut pour une colonne est nulle, Comment puis-je permettre à l'utilisateur d'entrer cette valeur nulle.
disons un nouvel utilisateur est créé sur un système. Il y a un champ prénom et nom de famille; le nom de famille est requis alors que le prénom ne l'est pas. Lors de la création de l'utilisateur, la personne verra 2 Texte entrées, une pour le premier et le dernier. La personne choisit d'entrer seulement le nom de famille. Le prénom n'est techniquement pas fixé. Pendant l'insertion, je vérifie la longueur de chaque champ, en positionnant tous les champs vides à NULL.
en regardant la base de données, je vois que le prénom n'est pas défini. La question qui vient immédiatement à l'esprit est que peut-être ils n'ont jamais vu le champ de prénom (c.-à-d., en raison d'une erreur). Mais ce n'est pas le cas; ils sont partis s'ils étaient Vierges.
alors, ma question est, comment décidez-vous quand un champ doit être défini à NULL ou une chaîne vide quand vous recevez l'entrée de l'utilisateur? Comment savez-vous que l'utilisateur veut que le champ ne soit pas défini sans détecter focus ou s'il a supprimé une valeur...ou...ou...?
question connexe: devrais-je utiliser une chaîne de caractères vide ou nulle pour représenter aucune donnée dans la colonne de la table?
8 réponses
Je n'utilise presque jamais NULL lorsque je me réfère à des données réelles. Lorsqu'il est utilisé pour les clés étrangères, je dirais que NULL est valide, mais il n'est presque jamais valide pour l'utilisateur saisit des données. La seule exception qui apparaîtrait probablement assez régulièrement concerne les dates qui n'existent pas, comme une base de données d'employés avec un champ "termination_date". Dans ce cas, tous les employés actuels devraient avoir une valeur nulle dans cette zone. Comme pour les faire entrer réellement une valeur nulle, pour les valeurs qui require a null value, je mettrais une case à cocher à côté du champ d'entrée pour que l'utilisateur puisse le cocher on et off pour voir la valeur correspondante à null (ou d'une manière plus conviviale, none). Lorsque vous activez la case à cocher pour définir le champ à null, la zone de texte correspondante doit être désactivée, et si une valeur null est déjà associée, elle doit commencer comme désactivée, et ne sera activée que lorsque l'utilisateur décochera la case à cocher null.
je vais briser le modèle, et dire que je voudrais toujours utiliser NULL pour chaînes de longueur zéro, pour les raisons suivantes.
-
si vous commencez à trancher les implications des blancs, alors vous devez vous assurer d'une façon ou d'une autre que chaque autre développeur le lit et l'écrit de la même manière.
-
comment l'alphabétisez-vous?
-
pouvez-vous déterminer sans ambiguïté quand un utilisateur omettre d'entrer une valeur, au lieu de la laisser intentionnellement en blanc?
-
Comment demander sans ambiguïté la différence? Un utilisateur de l'écran de requête peut-il indiquer " nul "par rapport à "blanc" en utilisant la syntaxe standard du formulaire d'entrée?
-
dans la pratique, je n'ai jamais été interdit de lire et d'écrire des données en utilisant par défaut, un comportement sans surprise en utilisant cette règle. Si j'ai besoin de savoir la différence, j'ai utilisé un booléen champ (qui est plus facile à associer à des dispositifs D'interface utilisateur non ambigus). Dans un cas, j'ai utilisé un déclencheur pour forcer la valeur True => null, mais je ne l'ai jamais vu invoqué parce que la couche BR filtrait efficacement la condition.
si l'utilisateur fournit une chaîne vide, je la traite toujours comme nulle du point de vue de la base de données. En outre, je vais généralement couper mes entrées de corde pour enlever les espaces de tête / arrière et puis vérifier si elles sont vides. C'est une petite victoire dans la base de données avec les types varchar() et cela réduit également les cas pour la recherche puisque je n'ai besoin de vérifier pour name is null au lieu de name is null or name = '' vous pourriez également aller dans l'autre sens, en convertissant null En ". Dans les deux cas, choisissez un moyen et soyez cohérent.
Ce que vous devez faire est de trouver ce comportement vous voulez. Il n'y a pas une algèbre fixe de la façon dont les chaînes de noms sont interprétées.
pensez à la machine d'état ici: vous avez des champs qui ont plusieurs états: il s'élance comme vous pensez à un État de" unitialized", un autre de" intentionnellement vide " et un troisième avec une certaine valeur définie. Tout ce que vous faites qui rend cette tâche et est compatible avec le reste de votre programme be find; il semble que la cartographie facile est
NULL → non initialisé
""→ désactivé intentionnellement
un nom → initialisé.
j'essaie de garder les choses simples. Dans ce cas, je rendrais la colonne du prénom inapplicable et j'autoriserais les blancs. Sinon, vous aurez trois cas à traiter où que vous vous référez à ce champ:
- prénom vide
- Null prénom
- Prénom Non vide
si vous utilisez "blank is null" ou "null is blank", vous n'avez plus que deux cas. Deux cas valent mieux que trois.
pour répondre à votre question: l'utilisateur saisissant des données ne sait probablement pas (et ne devrait pas) quoi que ce soit au sujet de ce qu'est un" null "et comment il compare à un"vide". Cette question devrait être réglée de façon claire et uniforme dans le système, et non dans L'assurance-chômage.
alors que votre exemple est principalement pour les cordes, j'aime à dire que j'utilise null pour les champs numériques et booléens. Un solde de compte de 0 est très différent pour moi comme un qui est nul. Même chose pour les booléens, si les gens prennent un test à choix multiple avec des réponses vraies et fausses, il est très important de savoir si quelqu'un a répondu vrai ou faux ou n'a pas répondu du tout. Ne pas utiliser null dans ces cas-là me demanderait d'avoir une table supplémentaire ou une configuration différente pour voir si quelqu'un a répondu question. Vous pouvez utiliser par exemple -1 pour non rempli en 0 pour false et 1 pour true, mais alors vous utilisez un champ numérique pour quelque chose qui est essentiellement un booléen.
Je n'ai jamais, jamais eu d'utilisation pour une valeur nulle dans le code de production. Une chaîne vide est une valeur sentinelle fine pour un champ de nom vierge, un numéro de téléphone, ou un revenu annuel pour n'importe quelle application. Cela dit, je suis sûr que vous pourriez trouver un certain usage pour elle, mais je pense qu'il est juste surutilisé. Si je était pour utiliser une valeur nulle, cependant, j'imagine que je l'utiliserais n'importe où je veux représenter une valeur vide.
j'ai toujours utilisé NULL pour les valeurs non initialisées, empty pour les valeurs volontairement vides et 0 pour les indicateurs off.
en faisant cela tout le temps, il est là même si Je ne l'utilise pas, mais je n'ai pas à faire quelque chose de différent si j'ai besoin de cette distinction.
je teste habituellement empty() , mais parfois je vérifie isset() qui évalue false sur NULL . Ceci est utile pour rappels pour répondre à certaines questions. Si c'est empty , false ou 0 alors la question est répondue.