Valeur NULL par défaut non prise en compte

**berthos** · 22/12/2016, 08h19

Bonjour,

J'ai mis par défaut la valeur NULL sur plusieurs champs, mais lors que je fais un INSERT sans renseigner ces champs, la valeur par défaut ne s'applique pas alors que les valeurs type integer par défaut s'appliquent.

Comme exemple, la valeur par défaut ne s'applique pas lors d'un INSERT pour les champs Nom2 et NomAnglais.

Quelqu'un a une idée ?

Voici la structure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE IF NOT EXISTS `langues_famille` (
  `Id` int(11) NOT NULL COMMENT 'Identifiant de la famille de langues',
  `Nom` varchar(50) DEFAULT NULL COMMENT 'Nom de la famille de langues',
  `Nom2` varchar(500) DEFAULT NULL COMMENT 'Liste des Nom2',
  `NomAnglais` varchar(50) DEFAULT NULL COMMENT 'Liste des noms anglais de la famille de langue',
  `Type_Id` int(11) NOT NULL DEFAULT '2' COMMENT 'Identifiant du type d''élément',
  `Dossier` varchar(50) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL COMMENT 'Répertoire d''enregistrement des ressources pour cet enregistrement',
  `Date_Modification` datetime DEFAULT NULL COMMENT 'Date de modification de l''enregistrement',
  `Autre` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Enregistrement différent',
  `Date_Creation` datetime DEFAULT NULL COMMENT 'Date de création de l''enregistrement'
) ENGINE=InnoDB AUTO_INCREMENT=92 DEFAULT CHARSET=utf8;

L'INSERT se fait de la façon suivante : (c'est un INSERT factorisé à l'ensemble de mes tables)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function Element_Ajouter($Table_Nom)
/*
But : Ajouter un Element 
Paramètres : $Table_Nom (Nom de la table de l'élément)
Résultat : l'Id de l'élément créé
*/
{
	$Phrase_SQL = "INSERT INTO ".$Table_Nom." 
					(`Date_Modification`, `Date_Creation`) 
					VALUES 
					('".date('Y-m-d H:i:s')."', '".date('Y-m-d H:i:s')."');";
	$result = mysql_query($Phrase_SQL) or die (mysql_error());
	$result = mysql_query("SELECT LAST_INSERT_ID();"); 
	$last_id = mysql_fetch_array($result);
	SQL_Enregistre($Phrase_SQL);
	return $last_id[0];
}

Merci d'avance

**escartefigue** · 22/12/2016, 08h54

Bonjour,

Pourquoi dites vous que la valeur par défaut ne s'applique pas, que trouvez vous après insert dans les colonnes "DEFAULT NULL" ?
Pourquoi avoir modélisé une table dont l'essentiel des colonnes est nullable et dont la valeur par défaut est NULL ? en particulier la date de création
Pourquoi récupérez vous le LAST_INSERT_ID() alors qu'aucune colonne de votre table n'est de type AUTO_INCREMENT ?

Enfin petite précision sémantique, NULL n'est pas vraiment une valeur, mais plus précisément un marqueur

**berthos** · 22/12/2016, 12h04

En effet, je n'ai pas écrit toute la définition de la table, voici le complément :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
-- Index pour la table `langues_famille`
--
ALTER TABLE `langues_famille`
  ADD PRIMARY KEY (`Id`),
  ADD UNIQUE KEY `Dossier` (`Dossier`),
  ADD UNIQUE KEY `Nom` (`Nom`),
  ADD KEY `fk_langues_famille_langues_famille_type_01` (`Type_Id`);
 
--
-- AUTO_INCREMENT pour les tables exportées
--
 
--
-- AUTO_INCREMENT pour la table `langues_famille`
--
ALTER TABLE `langues_famille`
  MODIFY `Id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Identifiant de la famille de langues',AUTO_INCREMENT=92;
--
-- Contraintes pour les tables exportées
--
 
--
-- Contraintes pour la table `langues_famille`
--
ALTER TABLE `langues_famille`
  ADD CONSTRAINT `fk_langues_famille_langues_famille_type_01` FOREIGN KEY (`Type_Id`) REFERENCES `langues_famille_type` (`Id`);

Donc il y a bien un Id créé et récupéré. J'ai fait le choix des NULL pour factoriser au maximum la création d'élément dans mes 22 tables avec une seule fonction et de les sécuriser avec les FOREIGN KEY.

**berthos** · 22/12/2016, 12h09

Envoyé par escartefigue

Bonjour,

Pourquoi dites vous que la valeur par défaut ne s'applique pas, que trouvez vous après insert dans les colonnes "DEFAULT NULL" ?
Pourquoi avoir modélisé une table dont l'essentiel des colonnes est nullable et dont la valeur par défaut est NULL ? en particulier la date de création
Pourquoi récupérez vous le LAST_INSERT_ID() alors qu'aucune colonne de votre table n'est de type AUTO_INCREMENT ?

Enfin petite précision sémantique, NULL n'est pas vraiment une valeur, mais plus précisément un marqueur

Pour la sémantique du NULL, je suis preneur d'explications, je me coucherai moins bête ce soir, car dans phpMyAdmin, il est proposé ce "choix" par défaut et j'en ai besoin car comme je mets des contraintes FOREIGN KEY, à la création j'ai besoin d'un NULL puis avec ma fonction de CLASS Enregistrer je précise les valeurs pour chacune de mes 22 tables selon les champs de chaque table.

Donc je suis tout ouie pour apprendre de nouvelles choses de votre part.

Merci d'avance

**escartefigue** · 22/12/2016, 13h48

Le NULL n'est pas une valeur, c'est même tout le contraire, ce marqueur indique l'absence de valeur.
Le plus souvent, la présence de NULL est symptomatique d'une modélisation hasardeuse, et du non respect des formes normales.

Vous n'avez pas répondu sur la valeur que vous obtenez dans les colonnes qui sont sensées être nulles, qu'en est-il ?

Pourquoi souhaitez vous centraliser dans une seule fonction les insertions qui concernent différentes tables ?

**berthos** · 28/12/2016, 18h17

Bonsoir,

J'ai tendance à utiliser NULL comme l'absence de valeur assignée à un champ pour faire la différence avec une valeur assignée car la chaîne vide n'est pas forcément une absence de valeur ou du moins me paraît moins explicite.
Donc dans ma programmation, le NULL est volontaire et géré.

Mais je suis prêt à apprendre comment mieux programmer.

L'INSERT renvoie un champ avec une chaîne vide.

Pour la centralisation, c'est tout simplement parce que j'ai factorisé au maximum les fonctions pour limiter au maximum les validations et limiter les risques de bugs lors des évolutions du programme.

Merci d'avoir pris le temps de me répondre.

Envoyé par escartefigue

Le NULL n'est pas une valeur, c'est même tout le contraire, ce marqueur indique l'absence de valeur.
Le plus souvent, la présence de NULL est symptomatique d'une modélisation hasardeuse, et du non respect des formes normales.

Vous n'avez pas répondu sur la valeur que vous obtenez dans les colonnes qui sont sensées être nulles, qu'en est-il ?

Pourquoi souhaitez vous centraliser dans une seule fonction les insertions qui concernent différentes tables ?

**SQLpro** · 29/12/2016, 10h17

Envoyé par berthos

Bonsoir,

J'ai tendance à utiliser NULL comme l'absence de valeur assignée à un champ pour faire la différence avec une valeur assignée car la chaîne vide n'est pas forcément une absence de valeur ou du moins me paraît moins explicite.
Donc dans ma programmation, le NULL est volontaire et géré.

Un des principes fondamentaux de base nde la modélisation des données est :
"Pas de NULL"

Les autres étant :

Pas de redondance
La modification d'une information ne dois pas entraîner la mise à jour de plus d'une ligne

Bien entendu ce "pas de null" signifie aussi, pas de valeurs fausses ( chaine vide, zéro, valeur arbitraire comme 31/12/9999...)

Tout ces problèmes se résolvent par une modélisation correcte utilisant les 4 premières formes normales.

Mais je suis prêt à apprendre comment mieux programmer.

Donc, cours de modélisation !

L'INSERT renvoie un champ avec une chaîne vide.

Pour la centralisation, c'est tout simplement parce que j'ai factorisé au maximum les fonctions pour limiter au maximum les validations et limiter les risques de bugs lors des évolutions du programme.

C'est tout le contraire qu'il faut faire ! Dans un univers ensemblistes (BD Relationnelles) les processus itératifs (fonctions) n'ont pas leur place sauf par exeception (quand il n'y a pas moyen de faire autrement).

Merci d'avoir pris le temps de me répondre.

A +

**berthos** · 29/12/2016, 10h51

Envoyé par SQLpro

Un des principes fondamentaux de base nde la modélisation des données est :
"Pas de NULL"

Par contre dans le cas présent, j'utilise les NULL aussi pour les FOREIGN KEYS car j'avais cru comprendre qu'on ne pouvait pas créer un enregistrement sans l'ID de la FOREIGN KEY sauf si on mettait NULL.
Car dans mon processus, je crée l'enregistrement vide d'abord pour avoir son ID et travailler sur l'objet puis une fois l'objet complété (et les objets liés) j'update l'enregistrement créé.
Est-ce correct ?

Envoyé par SQLpro

Donc, cours de modélisation !C'est tout le contraire qu'il faut faire ! Dans un univers ensemblistes (BD Relationnelles) les processus itératifs (fonctions) n'ont pas leur place sauf par exeception (quand il n'y a pas moyen de faire autrement).

Quand je dis que je factorise, c'est comme suit :
- Je crée une CLASS avec les propriétés et fonctions communes : Element_Class
- Je construis les autres CLASS sur cet Element_Class : class Article_Class extends Element_Class
- Et après j'ai tendance à sortir le code de mes classes pour les mettre dans des fichiers de FUNCTION pour les réutiliser sur plusieurs objets. Concrètement :
+ Class1 - Fonction 1 : Appelle une FUNCTION 1 (factorisée) + du code particulier à la CLASS1
+ Class2 - Fonction 1 : Appelle une FUNCTION 1 (factorisée) + du code particulier à la CLASS2

Est-ce correct ?

**pier.antoine** · 29/12/2016, 11h19

Bonjour

Par contre dans le cas présent, j'utilise les NULL aussi pour les FOREIGN KEYS car j'avais cru comprendre qu'on ne pouvait pas créer un enregistrement sans l'ID de la FOREIGN KEY sauf si on mettait NULL.
Car dans mon processus, je crée l'enregistrement vide d'abord pour avoir son ID et travailler sur l'objet puis une fois l'objet complété (et les objets liés) j'update l'enregistrement créé.
Est-ce correct ?

Pour ma part, qui suis loin d'être un spécialiste, je pense que ce n'est pas correct.

Il faut, à mon sens, déjà définir les valeur "externalisée", afin de s'en servir.

Exemple trivial :
Je ne vais pas créer une facture sans avoir au préalable créé le client.

Après, je dois avouer que parfois je triche un peu, c'est à dire que je créer une valeur dont le libellé est "non défini". Pour la clé étrangère, je désigne par défaut l'ID de ce libellé "Non défini".

Par exemple, l'achat de place de spectacle avec choix de l'emplacement. Je créé un emplacement "Non défini", et par défaut, l'achat d'une place à un emplacement "non défini".

Pierre

**SQLpro** · 29/12/2016, 11h22

Envoyé par berthos

Par contre dans le cas présent, j'utilise les NULL aussi pour les FOREIGN KEYS car j'avais cru comprendre qu'on ne pouvait pas créer un enregistrement sans l'ID de la FOREIGN KEY sauf si on mettait NULL.
Car dans mon processus, je crée l'enregistrement vide d'abord pour avoir son ID et travailler sur l'objet puis une fois l'objet complété (et les objets liés) j'update l'enregistrement créé.
Est-ce correct ?

Il est normal d'avoir des FK non renseignées, car les FK ne sont pas des informations mais des références à d'autres informations. Et c'est bien comme cela qu'il faut modéliser une base de données.

Quand je dis que je factorise, c'est comme suit :
- Je crée une CLASS avec les propriétés et fonctions communes : Element_Class
- Je construis les autres CLASS sur cet Element_Class : class Article_Class extends Element_Class
- Et après j'ai tendance à sortir le code de mes classes pour les mettre dans des fichiers de FUNCTION pour les réutiliser sur plusieurs objets. Concrètement :
+ Class1 - Fonction 1 : Appelle une FUNCTION 1 (factorisée) + du code particulier à la CLASS1
+ Class2 - Fonction 1 : Appelle une FUNCTION 1 (factorisée) + du code particulier à la CLASS2

Est-ce correct ?

Totalement incorrect. En effet il n'y a aucun rapport entre le monde objet des langages OO et le monde ensembliste des bases de données relationnelle. Raisonner en classe est relatif au monde objet. Dans le monde des bases de données relationnelle on raisonne de manière ensembliste à l'aide d'autres outils mathématique tel que les diagramme de Venn (appelés vulgairement "patates") ou encore pour modéliser, à l'aide des concepts d'entité et d'association (inventé par Peter Chen en 1976) dont la principale notation est la méthode MERISE en France. Tout autre tentative, et spécialement le raisonnement objet, conduira à des bases mal foutues et donc catastrophique en terme de performances... Les bases de données relationnelles ayant été créées pour manipuler des relations !
Dans votre exemple, cela s’appelle un héritage de données. Lisez les articles que j'ai écrit à ce sujet, notamment : http://sqlpro.developpez.com/cours/m...tion/heritage/

Pour vous former à la modélisation, lisez l'ouvrage que nous avons écrit :
Nom : Soutou Brouard Modélisation bases de données.jpg
Affichages : 856
Taille : 40,3 Ko

Nom : Soutou Brouard Modélisation bases de données.jpg
Affichages : 856
Taille : 40,3 Ko

A +

**berthos** · 29/12/2016, 11h31

Merci je vais étudier tout cela.
Je viens de commander votre livre et de mettre votre site à mon programme de formation.

Merci beaucoup.

Bonne journée et bonnes fêtes

Valeur NULL par défaut non prise en compte

Requêtes MySQL

Discussions similaires

Partager

Partager