Interview : Comment gérer la contrainte SQL NOT NULL en fin de code ?

Question

On m'a récemment posé cette question lors d'un entretien et j'ai du mal à formuler la question suffisamment bien pour trouver une réponse via le moteur de recherche.

Si ma base de données SQL a une contrainte NOT NULL placée sur la colonne "name", comment pourrais-je créer cette ligne, en la remplissant avec d'autres données, sans déclencher la contrainte NOT NULL de "name", en supposant que vous n'avez pas les données appropriées à insérer dans le champ "name" ?

Ma réponse spontanée a été d'insérer une chaîne vide dans le champ "nom", mais je pense que c'est trop compliqué. Quelqu'un connaît-il la bonne réponse ?

Answer 1

Il est généralement préférable d'insérer une valeur fictive, comme un -1, que vous pourrez facilement remplacer par la suite. Une chaîne vide peut être plus problématique dans certains cas. Pour ce faire, vous pouvez utiliser une instruction CASE WHEN ou, idéalement, une fonction ISNULL() qui ressemblerait à ceci ISNULL([ColName], -1) ISNULL est probablement la réponse qu'ils cherchaient. Elle insère les données si vous les avez et si elles sont nulles, elle insère un -1.

Comme Gordon l'a fait remarquer, vous pouvez également utiliser une valeur par défaut lors de la création du tableau. Dans ma réponse ci-dessus, je suppose que vous travaillez avec une table qui a déjà été créée - ce qui signifie que vous ne pouvez pas le faire sans modifier la table.

Answer 2

Il y a deux moyens auxquels je pense pour ne pas avoir à insérer name si c'est le cas NULL . Le plus simple, et de loin, est de définir une valeur par défaut :

alter table t alter column name varchar(255) not null default '<no name>';

L'alternative est d'utiliser un déclencheur, mais c'est beaucoup plus encombrant.

Si je posais une question similaire, c'est la réponse que je voudrais.

Answer 3

Pourquoi contourner la contrainte ?

A mon avis, soit vos données sont erronées, soit la contrainte.

Si vous contournez les contraintes, vous ne pouvez pas garantir la qualité des données dans la base de données.

Donc, je dirais que le scénario où une table ne peut pas être modifiée même si la contrainte est erronée est une énorme dette technique qui devrait être résolue à la place.