1. #1
    Membre expert
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 789
    Points : 3 992
    Points
    3 992

    Par défaut Question à propos des bonhommes NULL

    Bonjour,

    Lors de mon dernier séjour* parmi vous (pour le projet de gestion de gifts), j'avais fait connaissance avec la "sulfateuse anti NULL" (dixit CinePhil) de fsmrel.

    Ce qui a conduit au final une DB sans aucune colonne autorisant de valeurs nulle et c'est vrai que c'est pas mal pratique jusqu'ici pour le développement de l'applicatif qui s'appuie sur cette DB.

    Par contre je m'interroge. Dans ce cas, pourquoi la norme SQL prévoit-elle le marqueur NULL ?


    *
    je passe régulièrement lire quelques messages mais je préfère m'abstenir de donner de mauvais conseils.
    Kropernic

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 693
    Points : 28 261
    Points
    28 261

    Par défaut

    Je ne sais pas si c'est la réponse mais le marqueur NULL sert aussi de réponse du SGBD lors d'une requête avec une jointure externe lorsqu'il n'y a ps de ligne dans la table externe satisfaisant la condition de jointure. Il fallait donc bien qu'il figurât dans la norme SQL.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Membre expert
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 789
    Points : 3 992
    Points
    3 992

    Par défaut

    Ah oui, effectivement, dans ce cas, c'est bien utile.

    En ce qui me concerne, j'étais resté bloqué sur la possibilité d'indiquer qu'une colonne accepte le marqueur ligne comme "valeur" lors de la création d'une table.

    Puisque, si la DB est correctement normalisée, les bonhommes NULL disparaissent (si j'ai bien tout compris), je n'en vois pas l'intérêt.

    Mais votre exemple répond à la question telle que je l'avais posée.

    En fait, je me rends compte que je ne suis probablement pas sur le bon forum pour poser cette question.
    Kropernic

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    16 063
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 16 063
    Points : 37 068
    Points
    37 068

    Par défaut

    Comme le dit CinePhil, je résumerais par "chasser le NULL il revient au galop..." par la fait de la jointure externe !
    Dès lors la théorie de l'algèbre relationnelle est violée par le fait de cette apparition du NULL (en principe l’algèbre relationnelle manipule des relations à l'aide d'opérateurs qui donnent en sortie de nouvelles relations, donc avec clef, sans doublons et sans null....)

    Et puis il fallait bien permettre de reprendre les données pourries des fichiers Cobol ! On l'on avait pris l'habitude de mettre des date à blanc ou des date à 0000-00-00 ou 9999-99-99....

    En tout état de cause le NULL doit rester l'exception...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Membre expert
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 789
    Points : 3 992
    Points
    3 992

    Par défaut

    Merci pour ce complément de réponse.

    Je pense que la question est close
    Kropernic

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    5 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 971
    Points : 18 618
    Points
    18 618
    Billets dans le blog
    15

    Par défaut

    En ce qui concerne la jointure externe, n'oubliez pas que — dans le cas de SQL — COALESCE est utile pour empêcher le bonhomme Null de se manifester...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  7. #7
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Inscrit en
    novembre 2007
    Messages
    1 479
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 479
    Points : 5 180
    Points
    5 180
    Billets dans le blog
    5

    Par défaut

    Bonjour,

    Entre la théorie relationelle, et son implémentation dans les différents SGBDR il y a un gap. Il y a des points de la théorie qui ne sont pas implémentables de manière performante et scalable - en tout cas sur les technologies actuelles. Et le SQL c'est une norme pour uniformiser certains points d'implémentation. La plupart des editeurs de SGBDR on eu besoin d'implémenter NULL pour permettre des modèles physiques performants, et ils ont donc uniformisé cela dans la norme SQL.

    Citation Envoyé par Kropernic Voir le message
    Ce qui a conduit au final une DB sans aucune colonne autorisant de valeurs nulle et c'est vrai que c'est pas mal pratique jusqu'ici pour le développement de l'applicatif qui s'appuie sur cette DB.
    Le NULL permet d'enregistrer l'information 'valeur inexistante' dans la même ligne de la même table que les autres informations. Et donc - au niveau physique - de lire cette information sans i/o supplémentaire, de la mettre à jour sans verrou supplémentaire, et en plus de la stocker dans un espace minime (1 octet au maximum, parfois 0 suivant l'implémentation).

    Eliminer les colonnes NULLABLE oblige à mettre cette colonne dans une autre table. Y accéder va multiplier la conso i/o, CPU et les verrous. Et suivant qu'on choisisse de stocker l'information 'valeur inexistante' par une ligne dans une table (1), ou par l'absence de ligne (1) on va soit:
    (1) devoir stocker une clé primaire en plus pour chaque valeur inexistante
    (2) devoir vérouiller toute la table en repetable reads.


    Donc à réfléchir en fonction du SGBD et surtout en fonction de la criticité de la performance des accès à cette information (et sa scalabilité). Le SQL et les SGBDR offrent une possibilité d'avoir un modèle physique très performant en utilisant NULL a bon escient. Et où se l'interdire poserait de gros problèmes: de coût si on doit faire 3x plus d'i/o et utiliser 10x plus de CPU, et/ou de scalabilité si on doit vérouiller toute une table au lieu d'un enregistrement.

    Cordialement,
    Franck.
    Franck Pachot - Consultant et formateur en Suisse Romande (dbi services) - Oracle ACED - Oracle Certified Master 12c - twitter: @FranckPachot
    Essayer le Cloud Oracle: video tutorielle en 12 minutes


  8. #8
    Membre expert
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 789
    Points : 3 992
    Points
    3 992

    Par défaut

    Euh... ok.

    Sorry pour l'apparente ingratitude de ma réponse mais vos propos dépasse mon niveau d'expertise actuel...

    Je suis donc dans l'incapacité d'en apprécié la juste valeur pour le moment.

    Néanmoins, merci pour ce complément d'information.
    Kropernic

  9. #9
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Inscrit en
    novembre 2007
    Messages
    1 479
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 479
    Points : 5 180
    Points
    5 180
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par Kropernic Voir le message
    Sorry pour l'apparente ingratitude de ma réponse mais vos propos dépasse mon niveau d'expertise actuel...
    Ah. Désolé
    C'était juste pour dire qu'il y a de bonne raison pour avoir droit au NULL en SQL. Et qu'il me paraît dangereux de s'imposer ce genre de règles extrèmes (aucune colonne nullable) pour des raisons théoriques, sans avoir une bonne idée des conséquences lors de l'implémentation physique...

    Cordialement,
    Franck.
    Franck Pachot - Consultant et formateur en Suisse Romande (dbi services) - Oracle ACED - Oracle Certified Master 12c - twitter: @FranckPachot
    Essayer le Cloud Oracle: video tutorielle en 12 minutes


  10. #10
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 116
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 116
    Points : 4 587
    Points
    4 587

    Par défaut

    Bonjour à tous,

    Citation Envoyé par Pachot
    il me paraît dangereux de s'imposer ce genre de règles extrêmes (aucune colonne nullable)
    ==> tu as, en partie, raison (les extrêmes sont souvent mauvaises conseillères...). En effet, il est dommage, par exemple, de créer des tables pour gérer des données de type "Observations".

    En revanche, je pense qu'une colonne "clé étrangère", si elle peut être NULL, devrait toujours être externalisée (quand c'est possible sur le terrain). Pour ma part, la limite se situe à ce niveau.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. question à propos des containeurs
    Par bountykiller dans le forum C++
    Réponses: 4
    Dernier message: 02/10/2005, 14h21
  2. Question à propos des états
    Par rangernoir dans le forum IHM
    Réponses: 4
    Dernier message: 30/09/2005, 15h38
  3. Question à propos des compilateurs
    Par elf dans le forum Autres outils C & C++
    Réponses: 4
    Dernier message: 20/07/2005, 18h00
  4. Question à propos des niveaux de transaction
    Par davy.g dans le forum Oracle
    Réponses: 3
    Dernier message: 18/01/2005, 16h31
  5. Une question à propos des thread
    Par tscoops dans le forum C++Builder
    Réponses: 4
    Dernier message: 07/11/2003, 15h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo