p
u
b
l
i
c
i
t
é
publicité
  1. #1
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 499
    Points : 3 480
    Points
    3 480

    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 605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    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 605
    Points : 28 115
    Points
    28 115

    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
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 499
    Points : 3 480
    Points
    3 480

    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
    Inscrit en
    mai 2002
    Messages
    14 558
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 14 558
    Points : 32 303
    Points
    32 303

    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

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

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 499
    Points : 3 480
    Points
    3 480

    Par défaut

    Merci pour ce complément de réponse.

    Je pense que la question est close
    Kropernic

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

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 5 269
    Points : 15 354
    Points
    15 354
    Billets dans le blog
    6

    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 (Bonne lecture !)

  7. #7
    Modérateur
    Avatar de pachot
    Homme Profil pro
    Consultant DBA en Suisse (dbi services) ACE & OCM
    Inscrit en
    novembre 2007
    Messages
    1 416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant DBA en Suisse (dbi services) ACE & OCM
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 416
    Points : 4 900
    Points
    4 900
    Billets dans le blog
    4

    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 en Suisse Romande (dbi services) - Oracle ACE - Oracle Certified Master (OCP 12c et OCM 11g) - twitter: @FranckPachot

    Je serais au Paris Oracle Meetup le 4 septembre pour vous montrer comment je lis un rapport AWR et parler de l'option In-Memory



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

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 499
    Points : 3 480
    Points
    3 480

    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
    Modérateur
    Avatar de pachot
    Homme Profil pro
    Consultant DBA en Suisse (dbi services) ACE & OCM
    Inscrit en
    novembre 2007
    Messages
    1 416
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant DBA en Suisse (dbi services) ACE & OCM
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 416
    Points : 4 900
    Points
    4 900
    Billets dans le blog
    4

    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 en Suisse Romande (dbi services) - Oracle ACE - Oracle Certified Master (OCP 12c et OCM 11g) - twitter: @FranckPachot

    Je serais au Paris Oracle Meetup le 4 septembre pour vous montrer comment je lis un rapport AWR et parler de l'option In-Memory



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

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 117
    Points : 4 550
    Points
    4 550

    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, 13h21
  2. Question à propos des états
    Par rangernoir dans le forum IHM
    Réponses: 4
    Dernier message: 30/09/2005, 14h38
  3. Question à propos des compilateurs
    Par elf dans le forum Outils pour C & C++
    Réponses: 4
    Dernier message: 20/07/2005, 17h00
  4. Question à propos des niveaux de transaction
    Par davy.g dans le forum Oracle
    Réponses: 3
    Dernier message: 18/01/2005, 15h31
  5. Une question à propos des thread
    Par tscoops dans le forum C++Builder
    Réponses: 4
    Dernier message: 07/11/2003, 14h03

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