Comment sont les NULL et Varchar vide les valeurs stockées dans SQL Server . Et dans le cas où je n'ai pas d'entrée utilisateur pour une string sur mon UI je dois stocker un NULL ou un '' ?
Il y a un bon article ici qui traite de ce point. Ce qu'il faut retenir, c'est qu'il n'y a pas de différence dans la taille des tables, mais certains utilisateurs préfèrent utiliser une chaîne de caractères vide car cela peut faciliter les requêtes puisqu'il n'y a pas de vérification de NULL à faire. Il suffit de vérifier si la chaîne est vide. Une autre chose à noter est la signification de NULL dans le contexte d'une base de données relationnelle. Cela signifie que le pointeur vers le champ de caractères est défini sur 0x00 dans l'en-tête de la ligne, et qu'il n'y a donc pas de données accessibles.
Mise à jour Il y a un article détaillé ici qui parle de ce qui se passe réellement au jour le jour.
Chaque ligne a un bitmap nul pour les colonnes qui autorisent les nuls. Si la ligne de la colonne colonne est nulle, un bit du bitmap vaut 1, sinon il vaut 0.
Pour les types de données à taille variable, la taille réelle est de 0 octet.
Pour les types de données à taille fixe, la taille réelle est la taille par défaut du type de données. en octets fixée à la valeur par défaut (0 pour les nombres, '' pour les caractères).
le résultat de DBCC PAGE montre que les chaînes de caractères NULL et vides occupent toutes deux zéro octet .
Ce n'est pas vraiment une discussion sur le sujet. Il s'agit simplement de quelqu'un qui exprime son opinion sans rien pour l'étayer. Le seul point qu'ils ont soulevé est que les exigences en matière d'espace sont les mêmes et cela ne soutient aucune des deux méthodes.
"Une autre chose à noter est ce que NULL signifie dans le contexte d'une base de données relationnelle. Cela signifie que le pointeur vers le champ de caractères est défini à 0x00 dans l'en-tête de la ligne, donc aucune donnée à laquelle accéder." NULL ne signifie pas cela dans le contexte d'une base de données relationnelle. Cela signifie seulement que dans l'implémentation d'un fournisseur particulier d'une base de données relationnelle.
Faites attention aux nuls et à la vérification de l'inégalité dans le serveur sql.
Par exemple
select * from foo where bla <> 'something' ne renverra PAS les enregistrements où bla est nul. Même si, logiquement, il devrait le faire.
Donc la bonne façon de vérifier serait
select * from foo where isnull(bla,'') <> 'something' Ce que, bien sûr, les gens oublient souvent et obtiennent alors des bugs bizarres.
Il est déjà difficile d'accepter que "null = null" renvoie un résultat faux, mais que "null <> 'quelque chose'" renvoie également un résultat faux est tout simplement cruel.
@MikeTeeVee : Ce n'est pas FALSE dans les deux cas. C'est UNKNOWN et ne passe pas la condition (seulement TRUE le résultat passe).
La requête ci-dessus peut être optimisée un peu et elle sera un peu plus rapide. Au lieu de faire select * from foo where isnull(bla,'') <> 'something' vous pouvez faire select * from foo where (bla <> 'something') or (bla is null)
C'est une interprétation de NULL. Dans certains contextes, c'est clairement la bonne. Mais SQL n'est pas cohérent quand il s'agit de NULL, donc il y a des contextes où NULL signifie inconnu. Par exemple, "NULL != 'x'" renvoie NULL car dans ce contexte, NULL signifie inconnu. Si c'était une absence, cela n'aurait aucun sens, car 'x' n'est pas égal à une absence.
NULL est une valeur non définie, comme undefined. '' est une chaîne vide de 0 caractères.
La valeur d'une chaîne dans la base de données dépend de la valeur dans l'interface utilisateur, mais en général, c'est une chaîne vide. '' si vous spécifiez le paramètre dans votre requête ou procédure stockée.
S'il ne s'agit pas d'un champ de clé étrangère, le fait de ne pas utiliser de chaînes vides peut vous éviter des problèmes. n'autorisez les valeurs nulles que si vous considérez que null a une signification différente de celle d'une chaîne vide. par exemple, si vous avez un champ de mot de passe, une valeur nulle peut indiquer qu'un nouvel utilisateur n'a pas encore créé son mot de passe, alors qu'une valeur varchar vide peut indiquer un mot de passe vide. pour un champ comme "address2", autoriser les valeurs nulles ne peut que rendre la vie difficile. les choses à surveiller incluent les références nulles et les résultats inattendus des opérateurs = et <> mentionnés par Vagif Verdi, et surveiller ces choses est souvent une surcharge inutile pour le programmeur.
edit : si les performances sont un problème, voir cette question connexe : Types de données varchar nuls ou non nuls - lequel est le plus rapide pour les requêtes ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
En rapport : SQL : chaîne vide ou valeur NULL
0 votes
Si vous choisissez la voie de la chaîne vide, assurez-vous qu'elle est vide ! Supprimez tous les espaces ! Coupez-la deux fois si nécessaire pour être sûr qu'elle soit vide ! S'il vous plaît.