Question d'un néophyte (après recherche de bugs sur un pb de date à null) :
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour
les clefs étrangères optionnelles) et proposer une valeur par défaut ?
Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas LETULLIER
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que la "valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
A mon humble avis, tout est une question d'analyse conceptuelle, mais il
faut bien voir que NULL est une "valeur" également informative. Mettre une
valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par
défaut de ce champs implique que la personne est un nouveau-né, alors que la
"valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on
ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion
(calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL
utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le message
de news:%234vp6FvnDHA.2848@TK2MSFTNGP10.phx.gbl...
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour
les clefs étrangères optionnelles) et proposer une valeur par défaut ?
Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que la "valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
Frédéric LAMBOUR
En fait, je vient d'une base de donnée (non client serveur) ou les valeurs null n'existaient pas et je pense qu'il me faut en temps d'adaptation.
"Nicolas LETULLIER" a écrit dans le message de news:%
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que
la
"valeur" NULL que l'on traduirait par "valeur non définie" indique que
l'on
ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou
ISNULL
utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le
message
de news:% > Question d'un néophyte (après recherche de bugs sur un pb de date à
null)
: > > Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf
pour
> les clefs étrangères optionnelles) et proposer une valeur par défaut ? > Ce principe a-t-il des conséquences sur les performances de SQL serveur
?
> > Merci de vos réponses > >
En fait, je vient d'une base de donnée (non client serveur) ou les valeurs
null n'existaient pas et je pense qu'il me faut en temps d'adaptation.
"Nicolas LETULLIER" <nletullier@provibe.ASUPPRIMER.com> a écrit dans le
message de news:%238sbHQvnDHA.424@TK2MSFTNGP10.phx.gbl...
A mon humble avis, tout est une question d'analyse conceptuelle, mais il
faut bien voir que NULL est une "valeur" également informative. Mettre une
valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par
défaut de ce champs implique que la personne est un nouveau-né, alors que
la
"valeur" NULL que l'on traduirait par "valeur non définie" indique que
l'on
ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion
(calcul valeur, indexation, ...) seront compensés par les COALESCE ou
ISNULL
utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message
de news:%234vp6FvnDHA.2848@TK2MSFTNGP10.phx.gbl...
> Question d'un néophyte (après recherche de bugs sur un pb de date à
null)
:
>
> Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf
pour
> les clefs étrangères optionnelles) et proposer une valeur par défaut ?
> Ce principe a-t-il des conséquences sur les performances de SQL serveur
En fait, je vient d'une base de donnée (non client serveur) ou les valeurs null n'existaient pas et je pense qu'il me faut en temps d'adaptation.
"Nicolas LETULLIER" a écrit dans le message de news:%
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que
la
"valeur" NULL que l'on traduirait par "valeur non définie" indique que
l'on
ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou
ISNULL
utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le
message
de news:% > Question d'un néophyte (après recherche de bugs sur un pb de date à
null)
: > > Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf
pour
> les clefs étrangères optionnelles) et proposer une valeur par défaut ? > Ce principe a-t-il des conséquences sur les performances de SQL serveur
?
> > Merci de vos réponses > >
Patrice Scribe
J'utilise NULL si je suis convaincu qu'il importe de distinguer le cas ou la valeur n'est pas connue.
Par exemple pour une prévision : - la date prévisionnelle de début, je mettrais plutôt NOT NULL (si créer une prévision sans date prévue n'a aucun sens, dans un autre cas, il peut-être possible de prévoir un budget sans avoir la date dans ce cas je mets NULL etc...). - pour la date effective de fin, j'autorise NULL car la date est inconnue tant que l'activité n'est pas finie etc...
Pour les libellés, j'utilise souvent NOT NULL et une chaine vide par défaut, lorsque le fait que le libellé soit vierge ou non n'a aucune importance...
--
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
J'utilise NULL si je suis convaincu qu'il importe de distinguer le cas ou la
valeur n'est pas connue.
Par exemple pour une prévision :
- la date prévisionnelle de début, je mettrais plutôt NOT NULL (si créer une
prévision sans date prévue n'a aucun sens, dans un autre cas, il peut-être
possible de prévoir un budget sans avoir la date dans ce cas je mets NULL
etc...).
- pour la date effective de fin, j'autorise NULL car la date est inconnue
tant que l'activité n'est pas finie etc...
Pour les libellés, j'utilise souvent NOT NULL et une chaine vide par défaut,
lorsque le fait que le libellé soit vierge ou non n'a aucune importance...
--
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le message
de news:%234vp6FvnDHA.2848@TK2MSFTNGP10.phx.gbl...
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour
les clefs étrangères optionnelles) et proposer une valeur par défaut ?
Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
J'utilise NULL si je suis convaincu qu'il importe de distinguer le cas ou la valeur n'est pas connue.
Par exemple pour une prévision : - la date prévisionnelle de début, je mettrais plutôt NOT NULL (si créer une prévision sans date prévue n'a aucun sens, dans un autre cas, il peut-être possible de prévoir un budget sans avoir la date dans ce cas je mets NULL etc...). - pour la date effective de fin, j'autorise NULL car la date est inconnue tant que l'activité n'est pas finie etc...
Pour les libellés, j'utilise souvent NOT NULL et une chaine vide par défaut, lorsque le fait que le libellé soit vierge ou non n'a aucune importance...
--
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
Fred BROUARD
petite erreur NULL n'est pas une valeur, c'est justement l'inverse : l'absence de valeur. NULL est donc un marqueur comme NIL !
A +
Nicolas LETULLIER a écrit:
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que la "valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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 ****************** mailto: ******************
petite erreur NULL n'est pas une valeur, c'est justement l'inverse :
l'absence de valeur. NULL est donc un marqueur comme NIL !
A +
Nicolas LETULLIER a écrit:
A mon humble avis, tout est une question d'analyse conceptuelle, mais il
faut bien voir que NULL est une "valeur" également informative. Mettre une
valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par
défaut de ce champs implique que la personne est un nouveau-né, alors que la
"valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on
ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion
(calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL
utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le message
de news:%234vp6FvnDHA.2848@TK2MSFTNGP10.phx.gbl...
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour
les clefs étrangères optionnelles) et proposer une valeur par défaut ?
Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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
****************** mailto:brouardf@club-internet.fr ******************
petite erreur NULL n'est pas une valeur, c'est justement l'inverse : l'absence de valeur. NULL est donc un marqueur comme NIL !
A +
Nicolas LETULLIER a écrit:
A mon humble avis, tout est une question d'analyse conceptuelle, mais il faut bien voir que NULL est une "valeur" également informative. Mettre une valeur par défaut à tous tes champs pourrait amener à des aberrations.
Un exemple tout simple, l'age d'une personne. Mettre 0 comme valeur par défaut de ce champs implique que la personne est un nouveau-né, alors que la "valeur" NULL que l'on traduirait par "valeur non définie" indique que l'on ne connait pas son age.
Au niveau des performances, les traitements supplémentaires à l'insertion (calcul valeur, indexation, ...) seront compensés par les COALESCE ou ISNULL utilisés lors des requêtes.
Nicolas.
"Frédéric LAMBOUR" a écrit dans le message de news:%
Question d'un néophyte (après recherche de bugs sur un pb de date à null)
:
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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 ****************** mailto: ******************
Fred BROUARD
Non seulement NULL est nécessaire mais indispensable.
Comme l'on dit mes confrères, NULL possède un sens profond. Ce n'est d'ailleurs pas une valeur, puisque c'est justement l'inverse à savoir l'absence de valeur. Les exemples qui t'ont été montrés sur les problématiques de dates montre bien sa nécessité, car l'utilisation d'une date bidon fausserait par exemple toute requête de calculs statistique...
Mais les logiciens sont allés beaucoup plus loin... Voici ce que j'écris dans mon bouquin " Le problème des valeurs NULL a été bien décrit dans le livre de Joe Celko intitulé "SQL avancé". Joe Celko pose la question à peut près en ces termes : l'absence d'information est-elle due à son ignorance ou à son impertinence ? Pourquoi donc ne pas faire de différence entre la couleur du toit d'une voiture qui n'est pas connue, et la couleur du toit d'une moto qui n'est pas applicable ? Certains logiciens de l'algèbre relationnelle sont même allés plus loin en proposant différentes valeurs pour gérer les différents cas, en distinguant le "NULL" pour une valeur non renseignée, le "UNKNOWN" pour des valeurs existantes mais ne pouvant pas être saisies momentanément (la couleur des yeux d'une personne portant des lunettes de soleil par exemple) et le "INAPPLICABLE" pour une donnée qui n'a pas de sens dans le contexte (la couleur du toit d'une moto). "
On peut aussi raisonnablement penser qu'il est nécesaire d'introduire des marqueurs spécifique pour indiquer l'infini positif ou négatif dans des colonnes de type entier, réel ou date...
En effet comment indiquer avec certitude que la plage de validité temporelle d'une donnée est valable à partir du 1/3/1993 et ce pour une période illimitée ??? NULL indique simplement que la fin de cette période n'est pas connue...
A +
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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 ****************** mailto: ******************
Frédéric LAMBOUR a écrit:
Question d'un néophyte (après recherche de bugs sur un pb de date à null) :
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Merci de vos réponses
Non seulement NULL est nécessaire mais indispensable.
Comme l'on dit mes confrères, NULL possède un sens profond. Ce n'est
d'ailleurs pas une valeur, puisque c'est justement l'inverse à savoir
l'absence de valeur. Les exemples qui t'ont été montrés sur les
problématiques de dates montre bien sa nécessité, car l'utilisation
d'une date bidon fausserait par exemple toute requête de calculs
statistique...
Mais les logiciens sont allés beaucoup plus loin...
Voici ce que j'écris dans mon bouquin
"
Le problème des valeurs NULL a été bien décrit dans le livre de Joe
Celko intitulé "SQL avancé". Joe Celko pose la question à peut près en
ces termes : l'absence d'information est-elle due à son ignorance ou à
son impertinence ? Pourquoi donc ne pas faire de différence entre la
couleur du toit d'une voiture qui n'est pas connue, et la couleur du
toit d'une moto qui n'est pas applicable ?
Certains logiciens de l'algèbre relationnelle sont même allés plus loin
en proposant différentes valeurs pour gérer les différents cas, en
distinguant le "NULL" pour une valeur non renseignée, le "UNKNOWN" pour
des valeurs existantes mais ne pouvant pas être saisies momentanément
(la couleur des yeux d'une personne portant des lunettes de soleil par
exemple) et le "INAPPLICABLE" pour une donnée qui n'a pas de sens dans
le contexte (la couleur du toit d'une moto).
"
On peut aussi raisonnablement penser qu'il est nécesaire d'introduire
des marqueurs spécifique pour indiquer l'infini positif ou négatif dans
des colonnes de type entier, réel ou date...
En effet comment indiquer avec certitude que la plage de validité
temporelle d'une donnée est valable à partir du 1/3/1993 et ce pour une
période illimitée ??? NULL indique simplement que la fin de cette
période n'est pas connue...
A +
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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
****************** mailto:brouardf@club-internet.fr ******************
Frédéric LAMBOUR a écrit:
Question d'un néophyte (après recherche de bugs sur un pb de date à null) :
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour
les clefs étrangères optionnelles) et proposer une valeur par défaut ?
Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
Non seulement NULL est nécessaire mais indispensable.
Comme l'on dit mes confrères, NULL possède un sens profond. Ce n'est d'ailleurs pas une valeur, puisque c'est justement l'inverse à savoir l'absence de valeur. Les exemples qui t'ont été montrés sur les problématiques de dates montre bien sa nécessité, car l'utilisation d'une date bidon fausserait par exemple toute requête de calculs statistique...
Mais les logiciens sont allés beaucoup plus loin... Voici ce que j'écris dans mon bouquin " Le problème des valeurs NULL a été bien décrit dans le livre de Joe Celko intitulé "SQL avancé". Joe Celko pose la question à peut près en ces termes : l'absence d'information est-elle due à son ignorance ou à son impertinence ? Pourquoi donc ne pas faire de différence entre la couleur du toit d'une voiture qui n'est pas connue, et la couleur du toit d'une moto qui n'est pas applicable ? Certains logiciens de l'algèbre relationnelle sont même allés plus loin en proposant différentes valeurs pour gérer les différents cas, en distinguant le "NULL" pour une valeur non renseignée, le "UNKNOWN" pour des valeurs existantes mais ne pouvant pas être saisies momentanément (la couleur des yeux d'une personne portant des lunettes de soleil par exemple) et le "INAPPLICABLE" pour une donnée qui n'a pas de sens dans le contexte (la couleur du toit d'une moto). "
On peut aussi raisonnablement penser qu'il est nécesaire d'introduire des marqueurs spécifique pour indiquer l'infini positif ou négatif dans des colonnes de type entier, réel ou date...
En effet comment indiquer avec certitude que la plage de validité temporelle d'une donnée est valable à partir du 1/3/1993 et ce pour une période illimitée ??? NULL indique simplement que la fin de cette période n'est pas connue...
A +
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / 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 ****************** mailto: ******************
Frédéric LAMBOUR a écrit:
Question d'un néophyte (après recherche de bugs sur un pb de date à null) :
Pourquoi ne pas systématiquement non autoriser les valeur Null (sauf pour les clefs étrangères optionnelles) et proposer une valeur par défaut ? Ce principe a-t-il des conséquences sur les performances de SQL serveur ?
