NULL vs Empty lorsqu'il s'agit d'une entrée utilisateur

Question

Oui, une autre question NULL vs chaîne vide.

Je suis d'accord avec l'idée que NULL signifie non défini, tandis qu'une chaîne vide signifie "une valeur vide". Voici mon problème: si la valeur par défaut d’une colonne est NULL, comment puis-je permettre à l’utilisateur de saisir ce NULL.

Supposons qu'un nouvel utilisateur est créé sur un système. Il y a un champ prénom et nom; 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 entrées de texte, une pour le premier et une pour le dernier. La personne choisit d’entrer uniquement le nom de famille. Le prénom n'est techniquement pas défini. Lors de l’insertion, je vérifie la longueur de chaque champ en définissant tous les champs vides sur NULL.

Lorsque je regarde la base de données, je constate que le prénom n'est pas défini. La question qui me vient immédiatement à l’esprit est qu’ils n’ont peut-être jamais vu le champ du prénom (c.-à-d. À cause d’une erreur). Mais ce n'est pas le cas; ils sont partis s'ils étaient vides.

Ma question est donc la suivante: comment décidez-vous qu’un champ doit être défini sur NULL ou sur une chaîne vide lors de la réception d’une entrée utilisateur? Comment savoir que l'utilisateur souhaite que le champ ne soit pas défini sans détection du focus ou s'il a supprimé une valeur ... ou ... ou ...?

Question connexe: devrais-je utiliser NULL ou une chaîne vide ne représentant aucune donnée dans la colonne du tableau?

Answer 1

Je n’utilise presque jamais NULL pour faire référence à des données réelles. Lorsqu'il est utilisé pour les clés étrangères, je dirais que NULL est valide, mais ce n'est presque jamais valide pour les données entrées par l'utilisateur. La seule exception qui surviendrait probablement assez régulièrement concerne les dates qui n'existent pas, telles qu'une base de données d'employés avec une "date de terminaison". champ. Dans ce cas, tous les employés actuels doivent avoir la valeur NULL dans ce champ. Pour les amener à saisir une valeur null, pour les valeurs qui nécessitent réellement une valeur null, je voudrais cocher une case à côté du champ de saisie afin que l'utilisateur puisse l'activer et le désactiver pour afficher la valeur correspondante à null (ou de manière plus conviviale, aucune). Lorsque vous activez la case à cocher pour définir le champ sur 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 étant désactivée et ne devient activée que lorsque l'utilisateur décoche la case null.

Answer 2

Je vais casser le motif et dire que j'utiliserais toujours NULL pour les chaînes de longueur nulle, pour les raisons suivantes.

1. Si vous commencez à préciser les implications des espaces, vous devez vous assurer que tous les développeurs le lisent et l'écrivent de la même manière.

2. Comment l'alphabetisez-vous?

3. Pouvez-vous déterminer sans ambiguïté à quel moment un utilisateur a omis d'entrer une valeur, par rapport à un espace laissé intentionnellement?

4. Comment interrogeriez-vous sans ambiguïté la différence? Un utilisateur d’écran de requête peut-il indiquer NULL ou vierge en utilisant la syntaxe de formulaire d’entrée standard?

5. En pratique, on ne m'a jamais interdit de lire et d'écrire des données en utilisant un comportement par défaut et sans surprise en utilisant cette règle. Si j'ai besoin de connaître la différence, j'ai utilisé un champ booléen (qui est plus facile à mapper vers des périphériques d'interface utilisateur non ambigus). Dans un cas, j'ai utilisé un déclencheur pour appliquer True = > Valeur nulle, mais ne l'a jamais vue invoquée, car la couche BR a filtré efficacement la condition.

Answer 3

Si l'utilisateur fournit une chaîne vide, je la traite toujours comme nulle (null) du point de vue de la base de données. De plus, je vais généralement couper mes entrées de chaîne pour supprimer les espaces de début et de fin, 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 le nombre de cas de recherche, car je n'ai qu'à vérifier si nom est null au lieu de nom est null ou name = '' Vous pouvez également procéder dans l'autre sens, en convertissant null en "". De toute façon, choisissez une méthode et soyez cohérent.

Answer 4

Ce que vous devez faire, c'est déterminer le comportement souhaité. Il n’existe pas une algèbre fixe de l’interprétation des chaînes de noms.

Pensez à la machine à états ici: vous avez des champs qui ont plusieurs états: ils sont comme si vous pensiez à un état de "unitialized", un autre de "délibérément vide". et un troisième avec une valeur définie. TOUT ce que vous ferez qui rend cette tâche cohérente avec le reste de votre programme sera trouvé; il semble que la cartographie facile est

NULL & # 8594; non initialisé
" " & # 8594; volontairement non défini
un nom & # 8594; initialisé.

Answer 5

J'essaie de garder les choses simples. Dans ce cas, je rendrais la colonne du prénom non nullable et autoriserais les blancs. Sinon, vous aurez trois cas à traiter où que vous vous référiez à ce champ:

1. Prénom vide
2. Prénom nul
3. Prénom non vide

Si vous choisissez 'blank is null' ou 'null is blank', il ne vous reste plus que deux cas. Deux cas valent mieux que trois.

Pour répondre davantage à votre question, l'utilisateur qui saisit des données ne sait probablement pas (et ne devrait pas) savoir ce qu'est un " null " est et comment il se compare à un "vide". Ce problème doit être résolu de manière propre et cohérente dans le système, et non dans l'interface utilisateur.

Answer 6

Bien que votre exemple concerne principalement les chaînes, j'aime bien 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 solde nul. De même pour les booléens, si les gens passent un test à choix multiples avec des réponses vraies et fausses, il est très important de savoir si une personne a répondu vrai ou faux ou si elle n'a pas répondu du tout. Ne pas utiliser null dans ces cas me demanderait d'avoir une table supplémentaire ou une configuration différente pour voir si quelqu'un a répondu à une question. Vous pouvez utiliser par exemple -1 pour non renseigné, 0 pour false et 1 pour true, mais vous utilisez ensuite un champ numérique pour quelque chose qui est essentiellement un booléen.

Answer 7

Je n'ai jamais, jamais utilisé une valeur NULL dans le code de production. Une chaîne vide est une valeur sentinelle parfaite pour un champ de nom vierge, un numéro de téléphone ou un revenu annuel pour toute application. Cela dit, je suis sûr que vous pourrez en trouver l’utilisation, mais je pense que c’est surutilisé. Si je devais utiliser une valeur NULL, j'imagine que je l'utiliserais n'importe où si je veux représenter une valeur vide.

Answer 8

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, c'est là même si je ne l'utilise pas, mais je n'ai rien à faire d'autre si j'ai besoin de cette distinction.

Je teste généralement empty () , mais je vérifie parfois isset () qui évalue false sur NULL . Ceci est utile pour que les rappels répondent à certaines questions. Si est vide , faux ou 0 , la question reçoit une réponse.