Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 10 sur 10
  1. #1
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 944
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 944
    Points : 2 643
    Points
    2 643

    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 (anciennement Griftou).

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 817
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    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 : 13 817
    Points : 23 075
    Points
    23 075

    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
    2 944
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 944
    Points : 2 643
    Points
    2 643

    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 (anciennement Griftou).

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 418
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

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

    Informations forums :
    Inscription : mai 2002
    Messages : 13 418
    Points : 27 575
    Points
    27 575

    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
    2 944
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 944
    Points : 2 643
    Points
    2 643

    Par défaut

    Merci pour ce complément de réponse.

    Je pense que la question est close
    Kropernic (anciennement Griftou).

  6. #6
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 706
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 706
    Points : 12 558
    Points
    12 558

    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 Franck Pachot
    Consultant DBA en Suisse (dbi services) OCM 11g
    Inscrit en
    novembre 2007
    Messages
    1 366
    Détails du profil
    Informations personnelles :
    Nom : Homme Franck Pachot
    Âge : 43
    Localisation : Suisse

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

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 366
    Points : 4 071
    Points
    4 071

    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 Certified Master (OCP 12c et OCM 11g) - twitter: @FranckPachot


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

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 944
    Points : 2 643
    Points
    2 643

    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 (anciennement Griftou).

  9. #9
    Modérateur
    Avatar de pachot
    Homme Profil pro Franck Pachot
    Consultant DBA en Suisse (dbi services) OCM 11g
    Inscrit en
    novembre 2007
    Messages
    1 366
    Détails du profil
    Informations personnelles :
    Nom : Homme Franck Pachot
    Âge : 43
    Localisation : Suisse

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

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 366
    Points : 4 071
    Points
    4 071

    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 Certified Master (OCP 12c et OCM 11g) - twitter: @FranckPachot


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

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 011
    Points : 3 925
    Points
    3 925

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •