[info - SQLpro] - nouvel article : probématique des NULL

Julien

16/09/2004 à 14:42

Ah sympa, merci M'sieur :)

Juste comme ca, "violente" ça s'ecrit "violente" ou "violante" ?

"Fred BROUARD" a écrit dans le message de news:
Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Fred BROUARD

16/09/2004 à 17:15

je l'ai fait exprès, car c'étais violante au sens de violant la contrainte !!!

A +

Julien a écrit:

Ah sympa, merci M'sieur :)

Juste comme ca, "violente" ça s'ecrit "violente" ou "violante" ?

"Fred BROUARD" a écrit dans le message de news:
Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Thierry

16/09/2004 à 17:46

Fred,
Ton article, il est NULL ;-)

--
Thierry

PS : C'est génial, merci beaucoup !

--
Thierry

"Fred BROUARD" a écrit dans le message de news:

Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Julien

17/09/2004 à 10:00

Ah j'me doutais bien aussi qu'il y avait un "truc" ... !

"Fred BROUARD" a écrit dans le message de news:%
je l'ai fait exprès, car c'étais violante au sens de violant la contrainte !!!

A +

Julien a écrit:

Ah sympa, merci M'sieur :)

Juste comme ca, "violente" ça s'ecrit "violente" ou "violante" ?

"Fred BROUARD" a écrit dans le message de news:
Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Patrice

17/09/2004 à 14:09

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--

"Fred BROUARD" a écrit dans le message de
news:

Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--

"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:eqTb9b9mEHA.2340@TK2MSFTNGP11.phx.gbl...

Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--

"Fred BROUARD" a écrit dans le message de
news:

Bonjour,

tout ceci pour vous informer de la parution dans SQLpro
(http://sqlpro.developpez.com)
d'un article consacré à la problématique de l'absence de valeurs dans les
colonnes des tables.
Autrement dit des fameux *marqueurs* NULL.

A lire :
http://sqlpro.developpez.com/Null/SQL_NULL.html

Vos commentaires sont les bienvenus.

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Fred BROUARD

19/09/2004 à 12:43

assez d'accord, avec toi, mais là on en arrive à des régles "métiers", des
règles interne à l'entreprise donc du modèle et donc pas valable pour tous.

En outre, chaine vide et NULL peuvent être très distinct.
Par exemple une personne peut avoir d'autres prénoms que son prénom usuel. Il
est alors assez courant que l'on ajoute une colonne PRS_AUTRES_PRENOMS à la table.
La règle peut alors devenir :
NULL : on ne sait pas si la personne a d'autres prénoms.
'' : on sait que la personne n'a pas d'autres prénoms.
'Alfred' : on sait que la personne a d'autres prénoms, puisque la colonne est
rensaignée.

Mais note bien qu'il s'agit d'une règle et qu'elle peut être implémentée
différement dans d'autres entreprises.

Ainsi Celko préconise pour les colonnes DATETIME une colonne supplémentaire
permettant de reseigner si lors de la présence d'un NULL ou doit rechercher le
"toujours dans le futur" ou le "toujours dans le passé".

A +

Patrice a écrit:

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

assez d'accord, avec toi, mais là on en arrive à des régles "métiers", des
règles interne à l'entreprise donc du modèle et donc pas valable pour tous.

En outre, chaine vide et NULL peuvent être très distinct.
Par exemple une personne peut avoir d'autres prénoms que son prénom usuel. Il
est alors assez courant que l'on ajoute une colonne PRS_AUTRES_PRENOMS à la table.
La règle peut alors devenir :
NULL : on ne sait pas si la personne a d'autres prénoms.
'' : on sait que la personne n'a pas d'autres prénoms.
'Alfred' : on sait que la personne a d'autres prénoms, puisque la colonne est
rensaignée.

Mais note bien qu'il s'agit d'une règle et qu'elle peut être implémentée
différement dans d'autres entreprises.

Ainsi Celko préconise pour les colonnes DATETIME une colonne supplémentaire
permettant de reseigner si lors de la présence d'un NULL ou doit rechercher le
"toujours dans le futur" ou le "toujours dans le passé".

A +

Patrice a écrit:

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Vous avez filtré cet utilisateur ! Consultez son message

assez d'accord, avec toi, mais là on en arrive à des régles "métiers", des
règles interne à l'entreprise donc du modèle et donc pas valable pour tous.

En outre, chaine vide et NULL peuvent être très distinct.
Par exemple une personne peut avoir d'autres prénoms que son prénom usuel. Il
est alors assez courant que l'on ajoute une colonne PRS_AUTRES_PRENOMS à la table.
La règle peut alors devenir :
NULL : on ne sait pas si la personne a d'autres prénoms.
'' : on sait que la personne n'a pas d'autres prénoms.
'Alfred' : on sait que la personne a d'autres prénoms, puisque la colonne est
rensaignée.

Mais note bien qu'il s'agit d'une règle et qu'elle peut être implémentée
différement dans d'autres entreprises.

Ainsi Celko préconise pour les colonnes DATETIME une colonne supplémentaire
permettant de reseigner si lors de la présence d'un NULL ou doit rechercher le
"toujours dans le futur" ou le "toujours dans le passé".

A +

Patrice a écrit:

Bonjour Fred,

Je ne pense pas être un "intégriste" de l'éradication du NULL mais j'ai
l'impression qu'il est assez fréquent de voir des personnes qui ont un
problème parce qu'une colonne accepte "par inadvertance" la valeur NULL (ce
qui pose sans doute plus de problèmes que le contraire).

Cela peut dépendre de la nature des applications développées, mais d'après
mes constatations je commence déjà généralement par :
- pour numérique et chaîne, NOT NULL
- pour les dates, NULL (les dates tracent généralement des évènements à
venir)

Ensuite examen, avec les personnes concernées, de chaque donnée pour voir si
l'option contraite présente un intérêt (je ne suis *jamais* intégriste !).

A mon avis, autoriser NULL est plus souvent utile pour les nombres
(notamment pour distinguer avec le 0) que pour les chaines (si le prénom
d'une personne n'est pas connu, une chaine vide est suffisante pour
"constater" que le prénom n'est pas connu, la distinction entre prénom saisi
mais "vide" et prénom inconnu n'ayant généralement aucun intérêt).

D'une façon générale la distinction entre chaine vide et NULL pour les
chaines me semble rarement utile.

Cela pose aussi sinon un problème dans les interfaces utilisateurs ou la
distinction entre 0 et aucun affichage est visible, ce qui n'est pas le cas
entre une chaine vide et aucun affichage. Sans compter les problèmes
d'absorption par NULL alors que si le prénom n'est pas connu, on souhaite
généralement tout de même voir au moins le nom dans la colonne "Nom complet"
sur tel ou tel état, le summum etant de voir une base ou des prénoms peuvent
être soit vides soit NULLs...

Enfin pour les utilisateurs la notion de NULL me semble dans l'ordre
croissant de facilité de compréhension, les dates (tout le monde comprends
qu'une date future n'est pas encore connue), pour les nombres (c'est gratuit
ou le prix n'est pas connu) et enfin les chaines (le prénom est une chaine
vide ou n'est pas connu, cette distinction n'a généralement aucun intérêt
pour l'utilisateur)...

J'aime bien appeler NULL "valeur inconnue". Généralement, il est alors très
facile de comprendre que comparer une "valeur inconnue" à une *autre* valeur
inconnue n'a pas de sens ou qu'ajouter 1 à une valeur inconnue donne une
*autre* valeur inconnue.

Je pense qu'une petite conslusion pratique pourrait peut-être utile.
Notamment le choix entre NULL et chaine vide qui a mon avis a des
implications qui dépasse la simple modélisation de la base (restitution à
l'utilisateur dans l'UI).

Voilà pour mes quelques réflexions...

Patrice

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

[info - SQLpro] - nouvel article : probématique des NULL

6 réponses

Veuillez sélectionner un problème