L'utilisation de NULL dans les bases de données

[Maz]

Bonjour, j'aimerais avoir votre avis sur l'option "null" des colonnes dans les bases de données?

Utilisez-vous toujours des restrictions "NOT NULL" lorsque la colonne en question n'est pas censé avoir des données non-null (imaginons un champs "vie" sur les soldats d'un jeu). Ou vous contentez-vous de faire la vérification dans le code? (imaginons un champs "pseudo" sur les comptes d'un jeu).

[php_addict]

salut

perso je prefere mettre une valeur par défaut, exemple dans ton champs de vie je mettrais par défaut 0 et pour le pseudo je ne met rien du tout (ni NOT NULL ni par defaut)

Je ne sais pas si c'est une "bonne pratique", certains te le dirons

mais de toute façon dans le code il faut vérifier sur tu n'INSERT pas un pseudo vide ou un champs "vie" NULL

[Sephi-Chan]

Je me pose rarement la question : j'utilise des validations côté application.
Je n'utilise cette contrainte que pour les champs booléens.

[Maz]

Pourquoi seulement avec les booléen? Ne peut tu pas vérifier cette contrainte directement depuis l'application?

[Sephi-Chan]

Les booléens parce qu'ils n'ont que 2 états. Je ne veux vraiment pas du troisième. Pas de NULL et une valeur par défaut et ça roule.

Pour les autres types, j'utilise rarement de valeur par défaut, et si je le fais c'est avec la gem default_value_for. Donc pas besoin de m'embêter avec ça.

[Argorate]

En licence pro on a vu tout les problèmes et désavantages qu'apporter les NULL dans les BDD, je n'en ai jamais utilisé et je compte donc pas le faire, c'est source d'erreurs dans les requêtes pour rien...

[php_addict]

les NULL dans les BDD, [...], c'est source d'erreurs dans les requêtes pour rien...

n'hésites pas à nous en dire d’avantage

[Sephi-Chan]

En licence pro on a vu tout les problèmes et désavantages qu'apporter les NULL dans les BDD, je n'en ai jamais utilisé et je compte donc pas le faire, c'est source d'erreurs dans les requêtes pour rien...

La valeur NULL fait partie des SGBDR, l'éviter systématiquement est tout à fait bas-de-plafond et inapproprié.

n'hésites pas à nous en dire d’avantage

Et bien, il faut prévoir si tu dois jouer avec des valeurs NULL, sinon ça peut altérer les résultats. Notamment avec les jointures, les groupages, les agrégation, le tri, etc.

Par exemple dans le cas de jointures : si elles sont internes (INNER JOIN, ou JOIN tout seul, le INNER est implicite), si tu as une clé qui ne donne sur aucune entrée de la table jointe, la ligne entière ne sera pas ajoutée au jeu de résultat, alors que dans le cas d'une jointure externe (OUTER, LEFT, RIGHT), la ligne de la table source sera ajoutée mais les colonnes de la table jointes seront simplement à NULL.

Bref, ça peut facilement poser problème si on n'y prend pas garde. Heureusement, il y a plein d'outils pour les gérer (Working with NULL values, Comparison Functions and Operators !

[Argorate]

Je pense que s'encombrer d'une chose (dont pour l'instant je n'ai même jamais eut l'utilité) et qui peut être source d'erreurs n'est pas non plus le mieux.
Je dis pas que c'est impossible, je dis que ça demande du taff en plus pour pas grand chose.

Comme l'as dit en gros sephi, les null peuvent altérer les réponses d'une même requête en fonction de leur présence ou non, certaine requête sont créatrice de null.
Sur ce coup là, étant donné que je n'ai jamais eut le besoin de les utilisé, je ferais confiance au cours qu'on m'a donné (faudrait voir si je retrouve le policop sur les "null" ^^).

[srm]

J'utilise TOUJOURS null et is not null (pas les deux à la fois)

Si tu conçois correctement tes requêtes tu n'as aucun soucis.