Discussion :

[Nerva]

Ça c'est parfaitement assimilé depuis des lustres. Mais donc, pour les CHAR et compagnie, c'est l'intérêt de pouvoir utiliser soit l'un soit l'autre que je n'ai jamais réussi à assimiler. Quand un employé consulte le formulaire d'une personne et qu'il voit que dans le nom de jeune fille (je sais, ça n'existe plus) il n'y a rien d'inscrit, il n'a aucun moyen de savoir (et en tant qu'employé, ça lui importe peu) si c'est vide ou si c'est NULL. Tout ce que j'y vois comme différence, c'est de la complication que je juge inutile. Si la table a été remplie par un script effectué par un tiers et sur lequel on n'a eu aucun contrôle, ça implique de compliquer les requêtes avec des IS NULL OR = '' pour créer des filtrages.

NULL est une absence de valeur. Ok. Tu ajoutes que c'est parce que la valeur est inconnue. Ok aussi. Mais si la "cellule" est vide à la place de NULL, ça veut dire également qu'elle est inconnue, non ? Mais même "inconnue" amène des questions : inconnue parce qu'on ne la connaît pas, parce que l'information n'a pas encore été donnée ou inconnue parce qu'elle ne peut exister dans un cas précis, par exemple le nom de jeune fille pour un homme ?

Tu parles de la norme bancaire EMV où une valeur vide est valide pour certaines colonnes. Dans la structure de la table, ces colonnes ont une valeur par défaut paramétrée comme vide ou NULL ?

[escartefigue]

Le stockage dans la base de données est une chose, la facilité d'utilisation pour l'utilisateur en est une autre
Pour le nom marital, vide signifie qu'il n'y a pas de nom marital, on a l'information, alors que "null" signifie qu'il n'est pas connu, peut-être y en a-t-il un.
Mais pour l'utilisateur final, on peut restituer deux valeurs distinctes à l'écran ou sur les états, par exemple "néant" en italique quand la valeur est vide et "inconnu" en italique également quand la colonne est marquée "null". En italique ou avec tout autre typographie distinctive pour différencier les cas rares de personnes dont le nom marital serait "néant" ou "inconnu" ... ça doit pas se trouver tous les jours

[Nerva]

Pour le nom marital, vide signifie qu'il n'y a pas de nom marital, on a l'information, alors que "null" signifie qu'il n'est pas connu, peut-être y en a-t-il un.

Ça n'a pas de sens et ça me dépasse. Lorsqu'on saisit les coordonnées d'une nouvelle personne dans un formulaire (par exemple, à partir des infos qu'on a sur un document papier) où à la création d'une nouvelle ligne rien n'est encore rempli, soit on a l'information et on saisit la valeur, soit on ne l'a pas et la cellule reste NULL ; qu'il n'y ait pas de nom marital ou qu'il ne soit pas connu ne change rien à la manipulation. On ne peut pas saisir 2 guillemets simples pour transformer le NULL en vide.

[tatayo]

Quelle est la couleur des vitres latérales de ma voiture:

1. Bleu
2. Vert
3. Acune
4. Aucune idée

Dans l'avant dernier cas la valeur est vide (pas de couleur), et dans le dernier cas il n'y a pas de valeur => null.
C'est la différence entre "on sait qu'il n'y a rien" et "on ne sait pas ce qu'il y a".

tatayo

[escartefigue]

Ça n'a pas de sens et ça me dépasse. Lorsqu'on saisit les coordonnées d'une nouvelle personne dans un formulaire (par exemple, à partir des infos qu'on a sur un document papier) où à la création d'une nouvelle ligne rien n'est encore rempli, soit on a l'information et on saisit la valeur, soit on ne l'a pas et la cellule reste NULL ; qu'il n'y ait pas de nom marital ou qu'il ne soit pas connu ne change rien à la manipulation. On ne peut pas saisir 2 guillemets simples pour transformer le NULL en vide.

Dans certains cas en effet il est difficile de trancher entre l'un et l'autre, mais ce n'est pas toujours vrai, et il important de pouvoir distinguer le manque d'information d'une information validant que la donnée est absente.

[Nerva]

Vos réponses sont parfaitement cohérentes, mais que l'on connaisse ou non l'information, qu'elle soit applicable ou pas, comment différencie t'on, à la saisie (ou plutôt à la non-saisie), un vide d'un NULL ?

Code :

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

1
2
IND_DATE_DEBUT DATE NOT NULL,
IND_DATE_FIN DATE

Pour la première colonne, la date de début est obligatoire.
Pour la seconde colonne, cette date ne sera indiquée que lorsque le partenariat aura pris fin... et il prendra obligatoirement fin, tôt ou tard. À la création d'une ligne, la "valeur" de cette colonne est un marqueur NULL. Et elle est NULL, non pas parce que l'information n'existe tout simplement pas mais parce que elle n'existe pas encore à l'instant de la création de la ligne. Donc, si je suis votre raisonnement, sachant que tôt ou tard, une date sera saisie, elle devrait être paramétrée comme vide et non pas comme NULL.

D'où cette question : mis à part en exécutant un script INSERT INTO du genre ('2024-04-01', '') pour les colonnes qui contiendront obligatoirement une information, comment paramètre-t-on une valeur par défaut vide à la place de NULL dans un script de création de table ?

Et avec le nom de jeune fille :

- Pour un homme, il ne sera jamais rempli : c'est donc un NULL.
- Pour une femme, il sera peut-être rempli un jour : c'est donc un vide.

Là encore, dans la table, il n'y a qu'une seule colonne pour ça ; par défaut, ça ne peut pas être en même temps vide et NULL.

-----

@escartefigue. Je reviens au sujet initial. Dans la dernière structure que tu as présentée, avec type et sous-types, la date de fin n'est pas indiquée. Elle est pourtant obligatoire pour différencier les partenariats en cours et terminés et pouvoir appliquer les règles de gestion, que je rappelle de manière plus complète :

1) 1 interne peut avoir 0 ou plusieurs externes. Mais...
2) 1 interne ne peut avoir qu'1 externe à la fois, dans une période définie entre une date de début et une date de fin.
3) 1 interne peut avoir plusieurs fois le même externe tout en respectant la règle 2.
4) 1 externe peut avoir plusieurs externes simultanément.

[escartefigue]

Pour la seconde colonne, cette date ne sera indiquée que lorsque le partenariat aura pris fin... et il prendra obligatoirement fin, tôt ou tard. À la création d'une ligne, la "valeur" de cette colonne est un marqueur NULL. Et elle est NULL, non pas parce que l'information n'existe tout simplement pas mais parce que elle n'existe pas encore à l'instant de la création de la ligne. Donc, si je suis votre raisonnement, sachant que tôt ou tard, une date sera saisie, elle devrait être paramétrée comme vide et non pas comme NULL.

Vide n'est applicable que pour des types (n)(var)char. Pour les dates de fin, je préfère la valeur '9999-12-31' par défaut comme expliqué précédemment.

Et avec le nom de jeune fille :

- Pour un homme, il ne sera jamais rempli : c'est donc un NULL.
- Pour une femme, il sera peut-être rempli un jour : c'est donc un vide.

Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide et non pas null, null signifie "on n'a pas l'information, on ne sait pas". Or là, on sait.
Null est applicable au contraire pour une femme mariée dont on a le nom marital : l'absence du nom de naissance est un manque d'information, donc "null".

@escartefigue. Je reviens au sujet initial. Dans la dernière structure que tu as présentée, avec type et sous-types, la date de fin n'est pas indiquée. Elle est pourtant obligatoire pour différencier les partenariats en cours et terminés et pouvoir appliquer les règles de gestion, que je rappelle de manière plus complète :

C'est tout simplement parce que je n'ai communiqué qu'un MCD minimaliste, il faut évidemment l'enrichir avec les attributs qui vont bien :
on a besoin d'une date de fin, il suffit de l'ajouter dans l'association (ENC_encadrer)

[Nerva]

Alors je comprends la subtilité du raisonnement, mais j'y vois quand même des failles.

D'abord, la femme. Le nom de naissance que l'on ne possède pas existe pourtant bel et bien, contrairement par exemple à la couleur du toit d'un vélo, qui lui, on en est sûr et certain, n'existera jamais.

Ensuite, et c'est là que ça coince, je te cite :

"Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide"

"Null est applicable au contraire pour une femme mariée dont on a le nom marital : l'absence du nom de naissance est un manque d'information, donc "null"."

Dans une table contenant les coordonnées des employés, figurent les hommes et les femmes. La colonne "Nom de naissance" (comme les autres) étant commune aux deux sexes, comment, selon le cas, va-t-on définir que la "cellule" est vide ou NULL ?

Ensuite, j'arrête là...

-----

Pour ce qui est de mon affaire, reste une question, quelle est la meilleure méthode : table commune avec association réflexive ou tables avec sous-types ?

[escartefigue]

dans le cas où des hommes et des femmes sont présents, on utilise une colonne nullable, laissée à "null" dans un cas et alimentée à vide dans l'autre, tout simplement

D'une façon plus générale :

• je ne sais pas => marqueur "null"
• je sais qu'il n'y a pas de valeur pour cet attribut ==> valeur vide

[Nerva]

dans le cas où des hommes et des femmes sont présents, on utilise une colonne nullable, laissée à "null" dans un cas et alimentée à vide dans l'autre, tout simplement

Même si je n'en vois pas l'intérêt, j'avais parfaitement compris ce principe. Mais c'est la manière dont on alimente à vide une colonne NULL qui m'interpelle. L'employé de bureau ne saisit pas ses données avec un script SQL de remplissage.

Donc, encore une fois, comment, à partir du formulaire de saisie d'un logiciel transforme-t-on une cellule NULL en vide ?

On saisit deux fiches de personnes :

Dupont, [pas de nom de jeune fille], Catherine pour la dame.
Durant, [pas de nom de jeune fille], Pierre pour le monsieur.

La colonne 2 ayant une valeur par défaut NULL, comment la métamorphose-t-on en vide pour le monsieur en ne saisissant rien ?

[tatayo]

Peut-être avec une coche "non renseigné", où dans le cas d'une liste de sélection une valeur "N/A", "inconnu"...
Et c'est le code derrière le formulaire qui va interpréter cette info pour mettre à null la colonne correspondante.

Tatayo.

[Nerva]

Peut-être avec une coche "non renseigné", où dans le cas d'une liste de sélection une valeur "N/A", "inconnu"...
Et c'est le code derrière le formulaire qui va interpréter cette info pour mettre à null la colonne correspondante.

Ok, là d'accord. Mais quel intérêt de préciser une telle évidence ? Tout le monde sait qu'un homme n'a pas de nom de jeune fille et qu'une femme qui l'indique signifie qu'elle est mariée.

[tatayo]

Ok, là d'accord. Mais quel intérêt de préciser une telle évidence ? Tout le monde sait qu'un homme n'a pas de nom de jeune fille et qu'une femme qui l'indique signifie qu'elle est mariée.

En fait si, chacun des époux peut prendre le nom de l'autre époux: voici le texte de loi correspondant.

Quoi qu'il en soit j'ai un exemple très concret (malheureusement ).
J'ai un exemple très concret: lors de la création d'une fiche client en magasin, l'adresse email était facultative => NULL en cas d'absence.

Un jour la direction a décidé que l'adresse email devenait obligatoire (RGPD ? V.R.A.F.). Idée géniale s'il en est .
Comme le formulaire vérifiait la syntaxe de l'adresse, on ne pouvait pas saisir d'adresse vide. Du coup les vendeurs ont saisie des adresses "bidon", parfois avec un domaine valide, parfois non, et notre base client s'est retrouvée quelque peu "pourrave", et il est quasiment impossible de nettoyer ces adresses, à part les traiter au cas par cas.

Donc un NULL ici a toute sa place.

Tatayo.

[Nerva]

Pour le nom d'époux, les lois ont effectivement changé ; je me suis contenté de prendre un exemple ancien mais valide dans la pratique.

D'accord pour ton exemple, c'est du concret. Reste à mettre en doute, pour ce cas précis, le bien-fondé de la direction. Qu'à partir de telle date, l'adresse email devienne obligatoire pour les nouveaux inscrits, ok, mais alors, saisir des adresses bidon juste pour dire que les cases soient remplies, drôle d'idée... Par exemple, en vue d'une opération promotionnelle, comment contacter les anciens clients autrement que par courrier papier ? Comment différencier les anciens clients avec une adresse valide de ceux avec une adresse bidon ?

[SQLpro]

...
D'abord, la femme. Le nom de naissance que l'on ne possède pas existe pourtant bel et bien, contrairement par exemple à la couleur du toit d'un vélo, qui lui, on en est sûr et certain, n'existera jamais.
[...]
"Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide"

Sexisme et acculturation sont les deux mamelles du désastre.... Même s'il est courant que l'homme impose son patronyme au moment du mariage, ce n'est qu'une coutume et non de droit. le mari peut adopter le nom de son épouse. La notion de nom marital est, depuis des lustres remplacée officiellement par le terme "nom d'usage"...
https://www.service-public.fr/partic...vosdroits/F868

A +

[tatayo]

D'accord pour ton exemple, c'est du concret. Reste à mettre en doute, pour ce cas précis, le bien-fondé de la direction.

C'est bien ce que nous avions fait, freiner des 4 fers, mais rien n'y a fait.

Qu'à partir de telle date, l'adresse email devienne obligatoire pour les nouveaux inscrits, ok…

Bha non, un client peut très bien refuser de donner son adresse email.

, mais alors, saisir des adresses bidon juste pour dire que les cases soient remplies, drôle d'idée…

Les vendeurs n'avaient malheureusement pas d'autre choix.

Par exemple, en vue d'une opération promotionnelle, comment contacter les anciens clients autrement que par courrier papier ?

Le client s'exclue de fait de la campagne d'infos, c'est son choix.

Comment différencier les anciens clients avec une adresse valide de ceux avec une adresse bidon ?

C'est toute la difficulté, autant un domaine inexistant est identifiable (il suffit de chercher le MX correspondant), autant une adresse du genre bidon@free.fr est invérifiable.

Tatayo.

[Nerva]

@SQLPro : ce n'était qu'un exemple. Je ne me suis pas creusé la tête pour en trouver un autre.

Bha non, un client peut très bien refuser de donner son adresse email.

Je ne fais que te citer : "Un jour la direction a décidé que l'adresse email devenait obligatoire"

Perso je ne donne pas non plus mon adresse email à un magasin qui ne paramètre pas par défaut le non-envoi de spams publicitaires... c'est-à-dire que je ne la donne à aucun ! Même si il n'y a qu'à cocher une case (quand ça veut bien marcher !) pour ne plus rien recevoir, c'est une question de principe.

[Nerva]

Je reviens au sujet initial pour une précision...

Dans le but d'obtenir dans une requête la liste de tous les internes et de leur(s) externe(s) avec une cellule vide lorsque l'externe est inexistant, j'ai modifié (et simplifié ici) les 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
CREATE TABLE T_INDIVIDUS (
	IND_ID INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1) NOT NULL,
	IND_TYPE INTEGER NOT NULL,
	IND_NOM VARCHAR (50) NOT NULL,
	IND_PRENOM VARCHAR (50) NOT NULL,
	CONSTRAINT PK_IND_ID PRIMARY KEY (IND_ID)
);
 
CREATE TABLE T_PARTENARIATS (
	INT_ID INTEGER NOT NULL,
	EXT_ID INTEGER DEFAULT NULL,
	CONSTRAINT PK_INT_ID PRIMARY KEY (INT_ID),
	CONSTRAINT FK_INT_ID FOREIGN KEY (INT_ID) REFERENCES T_INDIVIDUS (IND_ID),
	CONSTRAINT FK_EXT_ID FOREIGN KEY (EXT_ID) REFERENCES T_INDIVIDUS (IND_ID),
	CONSTRAINT UC_INT_EXT UNIQUE (INT_ID, EXT_ID)
);

Ainsi que le jeu de données avec ajout d'une colonne INT_TYPE (1 interne, 2 externe) :

Code :

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

1
2
3
4
5
6
7
8
9
10
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (1, 1, 'Talbot', 'Maribelle');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (2, 1, 'Vidal', 'Pierre');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (3, 1, 'Nemours', 'Doralice');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (4, 1, 'Grimaud', 'Sarah');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (5, 1, 'Vassent', 'David');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (6, 1, 'Carpentier', 'Thomas');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (7, 1, 'Lefort', 'Julie');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (8, 1, 'Jodel', 'Karine');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (9, 2, 'Montepin', 'Victor');
INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (10, 2, 'Lasalle', 'Anne-Marie');

De 1 à 8 : internes
De 2 à 10 : externes

Pour que ça fonctionne, ça implique de saisir obligatoirement chaque interne dans T_PARTENARIATS avec un NULL dans la colonne EXT_ID lorsqu'il n'y a pas de partenariat. Exemple avec ce jeu :

Code :

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

1
2
3
4
5
6
7
8
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (1, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (2, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (3, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (4, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (5, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (6, NULL);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (7, 9);
INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (8, 10);

Ainsi, cette requête retourne ce que je désire :

Code :

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

1
2
3
4
5
6
SELECT
(I1.IND_NOM || ' ' || I1.IND_PRENOM) AS INTERNE,
(I2.IND_NOM || ' ' || I2.IND_PRENOM) AS EXTERNE
FROM T_PARTENARIATS P
INNER JOIN  T_INDIVIDUS I1 ON I1.IND_ID = P.INT_ID
LEFT OUTER JOIN  T_INDIVIDUS I2 ON I2.IND_ID = P.EXT_ID

Je pourrais ainsi ensuite ajouter d'autres tables, comme les adresses, les localités, afin de faire des "mailings", par exemple.

N'y aurait-il pas malgré tout une autre manière de procéder, plus académique, qui éviterait la saisie lorsqu'il n'y a pas de partenariat ?

[tatayo]

Bonjour,
Tu peux partir de la table individus pour récupérer les internes, puis faire une jointure externe sur la table partenariat puis sur individus pour avoir les externes liés:

Code sql :

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

1
2
3
4
5
6
7
8
 
Select *
From individus as int
Left outer join partenariat as p
Inner join individus as ext
On p.idext = ext.id
On p.idint = int.id
Where ext.type = 1

Je simplifie, c'est galère de taper sur une tablette... Mais c'est l'idée.

Tatayo

[escartefigue]

Ces tables simplifiées :

Je reviens au sujet initial pour une précision...

Dans le but d'obtenir dans une requête la liste de tous les internes et de leur(s) externe(s) avec une cellule vide lorsque l'externe est inexistant, j'ai modifié (et simplifié ici) les 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
CREATE TABLE T_INDIVIDUS (
	IND_ID INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1) NOT NULL,
	IND_TYPE INTEGER NOT NULL,
	IND_NOM VARCHAR (50) NOT NULL,
	IND_PRENOM VARCHAR (50) NOT NULL,
	CONSTRAINT PK_IND_ID PRIMARY KEY (IND_ID)
);
 
CREATE TABLE T_PARTENARIATS (
	INT_ID INTEGER NOT NULL,
	EXT_ID INTEGER DEFAULT NULL,
	CONSTRAINT PK_INT_ID PRIMARY KEY (INT_ID),
	CONSTRAINT FK_INT_ID FOREIGN KEY (INT_ID) REFERENCES T_INDIVIDUS (IND_ID),
	CONSTRAINT FK_EXT_ID FOREIGN KEY (EXT_ID) REFERENCES T_INDIVIDUS (IND_ID),
	CONSTRAINT UC_INT_EXT UNIQUE (INT_ID, EXT_ID)
);

Né répondent pas aux règles de gestion initialement exprimées :

Bonjour.

Soit une population d'individus. Il y a les internes, qui font partie d'un organisme (société, entreprise, administration, c'est sans importance) et les externes, qui sont des vacataires en partenariat avec des internes pour des missions temporaires.

- 1 interne peut avoir 0 ou 1 externe à la fois. Une date de début et de fin sont précisées à cet effet.
- 1 externe (qui n'existe que si il est missionné au moins 1 fois) peut être en partenariat avec 1 ou plusieurs internes, simultanément.

La clef primaire de la table partenariat est INT_ID qui référence IND_ID, donc un indentifiant d'interne ou d'externe puisqu'il n'y a pas de restriction sur le type d'individu.
Ce faisant, on ne peut ni lier un interne à plusieurs externes à des dates différents (viol de la règle 1), ni avoir plusieurs associations entre un interne et des externes (viol de la règle 2).