Je crois comprendre que les deux blocs de code suivants sont logiquement équivalents:
CREATE TABLE MyTable(Key INT PRIMARY KEY, Value INT NULL) CREATE TABLE MyTable(Key INT PRIMARY KEY, Value INT)
3 Réponses :
Lorsque vous souhaitez insérer dans la table, vous devez affecter une valeur à toutes les colonnes si elle n'utilise pas NULL, mais si une colonne a la valeur par défaut ou NULL (qui est une sorte de valeur par défaut), vous pouvez ignorer cette colonne.Pour exemple:
1,NULL
Vous n'avez pas besoin d'ajouter une définition dans le tableau pour défaut null code>. Avez-vous essayé ce que vous dites?
Oui. Si vous n'ajoutez pas de valeur par défaut (telle que NULL, etc.), vous devez ajouter ce champ dans chaque requête d'insertion / mise à jour.
Cela fonctionne bien dans MSSQL code> pour moi, et je ne trouve aucun problème pour cela, répondez spécifiquement où vous avez essayé que
Pouvez-vous exporter votre définition de table? @Shahjahan
J'ai créé une table avec cette commande Créer une table MyTable ([touche] INT Touche principale, Valeur Int) CODE> et Insérez la valeur à l'aide de votre commande Insérer dans des valeurs MyTable ([Key]) (1) code>. Tout fonctionne bien. La chose est lorsque vous n'avez pas ajouté null code> à votre définition, il ajoutera automatiquement null code> sur votre champ. C'est pourquoi je suis préoccupé par votre réponse
CREATE TABLE MyTable
(
Key INT PRIMARY KEY,
Value INT
)
Est-ce vrai? J'avais l'impression que les champs étaient facturables (pouvaient contenir une valeur nulle) par défaut.
@Dacromir: Cela pourrait dépendre du moteur RDBMS réel que vous utilisez - mais aussi loin que je sache, et pour tous les PDRM que je connais, vous avez raison et votre raunak est mal b> - Dans ce cas, les énoncés code> de table code> sont identiques et fournissent la même structure de table - une touche code> clé code> (qui est par définition non null code>) et a NULLLABLE B> Valeur Code> Colonne
Le contrainte SQL n'est pas une langue minimaliste. Il existe plusieurs façons d'exprimer exactement la même chose. P>
Dans ce cas, je pense que Cela dit, je dirais que la plupart des concepteurs de base de données le laissent sortir. P> null code> est la valeur par défaut lorsque vous définissez une colonne. Comme vous le dites, vos deux versions sont équivalentes, car SQL les définit comme équivalents. Exprimer une contrainte explicite NULL code> est à peu près les mêmes choses que de dire rejoindre interne code> plutôt que joindre code> ou y compris elv null code> dans un cas code> expression. p>
null code> est inclus pour deux raisons: p>
Deux cas viennent à l'esprit: 1) Conversion d'un champ
Not NULL CODE> Retour à unNULL CODE> CHAMP ACTABLE et 2) Juste pour être explicite sur les définitions de la colonne.La nullabilité par défaut est nullable, l'ajout code> null code> est généralement redondant. Vous voudrez peut-être l'ajouter à être explicite dans certains cas.