IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Modélisation des artistes


Sujet :

Schéma

  1. #1
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut Modélisation des artistes
    Bonjour,

    Je souhaite améliorer le modèle de ma base de données personnelle sur le cinéma et je me demande quelle est la meilleure manière de modéliser un artiste.
    La notion d'artiste est à prendre au sens très large de toute personne participant à un film (acteurs, réalisateur, techniciens...)

    Aujourd'hui, j'ai cette table :
    t_e_personne_prs (per_id, per_nom_reel, per_prenom_reel, per_nom_public, per_prenom_public, per_sexe, per_date_naissance, per_date_deces, per_pays_id, per_commentaire)

    Il y a pas mal de colonnes nullables dans cette table et c'est ça que je voudrais améliorer, convaincu par les arguments de fsmrel qui chasse le bonhomme NULL dans les vertes prairies du Relationland.

    1) Commençons par le plus facile : les dates.
    Je ne connais pas les dates de naissance de tous les artistes et encore moins leur date de décès puisque beaucoup sont encore en vie.
    Il convient donc de sortir les dates de naissance et de décès de cette table qui sera très sollicitée par mon programme.

    MCD :
    personne -0,1----naître----0,n- date
    |--------------0,1----décéder----0,n---|

    Comme je vais gérer pas mal de dates, en plus de celles ci-dessus (date de sortie d'un film, date de parution d'une revue ou d'un livre, date de projection en festival, dates de début et de fin d'un festival...), je vais probablement être amené à créer un calendrier en BDD. Peut-être toutefois pas aussi complexe que celui de SQLPro, mais j'envisage de séparer les jours, mois et années car je peux n'avoir l'information que d'une date imprécise (Untel est né en 1902 et mort en 1990) ou n'avoir besoin que du mois et de l'année, par exemple pour un magazine mensuel.

    Mon MCD simple ci-dessus ne devrait-il pas se complexifier en faisant 3 associations pour "naître" (vers jour, mois, année) et de même pour "décéder" ?
    Bref, comment modéliser le fait que la date peut être incomplète ?

    2) Plus compliqué peut-être : les noms.
    Si j'ai, dans ma table actuelle, séparé les noms et prénoms réels et publics, c'est parce que certains artistes sont connus sous un pseudonyme. Détail qui complique encore la chose, certains pseudonymes sont composés d'un nom et d'un prénom (Marylin Monroe) et d'autres seulement d'un nom (Arletty, Miou-Miou).

    Alors quoi mettre dans la table des personnes et quoi mettre dans une table séparée ?

    Première solution : Sortir le nom réel.
    Les artistes sont connus sous leur nom d'artiste, figurant au générique des films, que ce nom soit leur nom réel ou un pseudonyme.

    MCD :
    personne -0,1----avoir----(1,1)- nom_reel

    Mais si je sépare le nom et le prénom dans les deux tables résultant de ces deux entités types, je peux de nouveau voir apparaître le bonhomme NULL, par exemple pour Miou-Miou qui n'a pas de prénom dans son nom d'artiste.
    "Ben, t'as qu'à faire une seule colonne pour le nom d'artiste qui contiendra le nom et le prénom !
    - Oui mais, quand je vais vouloir afficher une liste d'artistes, j'aimerais que Marilyn Monroe soit classée à Monroe et pas à Marylin !"
    Il y aurait la solution d'écrire dans cette colonne unique "Monroe (Marylin)" et de reconstituer par programme le joli nom de "Marylin Monroe" lors de la présentation de la donnée, mais je trouve ça un peu moyen comme solution et pas très naturel à la saisie... bref, j'aime pas trop.

    Deuxième solution : Sortir le pseudonyme.
    Le nombre d'artiste ayant un pseudonyme est relativement faible. On pourrait alors suivre la majorité et externaliser les quelques fantaisistes qui ne sont pas assez fiers de leur patronyme !

    MCD :
    personne -0,1----avoir----(1,1)- pseudonyme

    Les problèmes soulevés précédemment sont là aussi présents (prénom optionnel) auquel s'ajoute le fait que je ne connais pas forcément le nom réel de certains artistes à pseudonyme, ce qui reviendrait à avoir des anonymes dans la table des personnes !

    Voilà où j'en suis de ma réflexion. Espérant que vous aurez eu le courage de me lire jusqu'au bout, j'attends vos commentaires et suggestions.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

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

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour CinePhil,

    Avant de parler du fond, il me semble que la chasse au bonhomme NULL ne devrait être déclenchée que pour les clés et clés étrangères, et non pour les attributs simples, non ?

    Si nous commençons à créer des entités (tables, en final) uniquement pour éviter que des attributs simples (champs sans correspondance avec d'autres tables, en final) soient NULL, alors nous n'avons pas fini...

    Ceci dit, ton fil est intéressant.
    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 !

  3. #3
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    il me semble que la chasse au bonhomme NULL ne devrait être déclenchée que pour les clés et clés étrangères, et non pour les attributs simples, non ?
    fsmrel ou SQLPro expliqueraient ça sûrement mieux que moi mais comme les noms et les dates peuvent être indexés, pour des besoins de recherche sur ces critères, il me semble que NULL rend les index beaucoup moins efficaces.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  4. #4
    Responsable Arduino et Systèmes Embarqués


    Avatar de f-leb
    Homme Profil pro
    Enseignant
    Inscrit en
    Janvier 2009
    Messages
    12 579
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Janvier 2009
    Messages : 12 579
    Points : 56 602
    Points
    56 602
    Billets dans le blog
    40
    Par défaut
    Bonjour,

    concernant les dates incomplètes, tu constateras dans son modèle des personnes, que la présence de Null ne gêne pas sqlPro dans son cas précis:

    Citation Envoyé par sqlPro
    Le découpage de la date de naissance en trois rubriques peut paraître curieux, mais il existe encore de nombreuses personnes de part le monde pour lesquels la date de naissance est incertaine (souvent juste l'année, parfois, l'année et le mois) naissant dans des pays ou l'état civil n'est pas aussi moderne que celui des pays civilisés (au_ vrai sens du terme pour une fois !).

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

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour CinePhil et Fabien,

    Point 1 :
    De mon point de vue, dans ton cas, la séparation de ces dates en 3 colonnes se justifie amplement (argument commun entre toi et SQLPro).
    La question est donc : est-il admissible que ces trois colonnes puissent être de valeur NULL ?
    ==> à mon sens, oui. La cohérence de la saisie peut être assurée par une fonction traitant les différents cas de saisie/non-saisie.

    Sinon, effectivement, tu pourrais créer les entités suivantes :
    Jour (jou_id, ...) ==> de 1 à 31 ;
    Mois (moi_id, ...) ==> de 1 à 12 ;
    Année (ann_id, ...) ==> de 1900 à 10000.
    avec les relations (intéressantes) :
    Jour ---(0,12)---[compose le mois]---(28,31)--- Mois ;
    Mois ---(1,n)---[compose l'année]---(12,12)--- Année.
    ==> de toutes façons, en final, la cohérence (31/02/xxxx) devra être testée (par un trigger, par exemple).



    Point 2 :
    Le seul attribut que l'on connaît, à coup sûr, est le nom public (sinon, il ne serait pas public) : Miou-Miou, Eddy Mitchell, etc...

    La relation que tu présentes
    Citation Envoyé par CinePhil
    personne -0,1----avoir----(1,1)- pseudonyme
    se discute. Celle-ci :
    personne -0,n----avoir----(1,n)- pseudonyme
    me paraît plus juste.

    En effet :
    • dans la carrière d'un même artiste, l'emploi de plusieurs pseudonymes est possible (pas d'exemple à te donner, mais peut se justifier par un changement "d'orientation") ;
    • un même pseudonyme peut, également, être ou avoir été celui de plusieurs personnes (pas d'exemple à te donner, mais les nouvelles générations peuvent ne pas avoir la liste, à jour, de tous les pseudonymes à ne pas utiliser).

    Pour le pseudonyme, une association serait donc la bienvenue, de par la conception.

    En revanche, pour le nom réel, je ne pense pas que ce soit nécessaire. Faire une table qui contiendrait "MOINE Jean-Claude" uniquement pour prévoir le fait qu'il peut y avoir d'autres artistes dont le nom réel serait "MOINE Jean-Claude", ne me semble pas pertinent. D'autre par, la valeur NULL du nom réel d'un artiste est un renseignement intéressant, en soi : l'externaliser pour ne pas avoir de valeur NULL dans la table, mais retrouver cette valeur NULL dans les différentes requêtes ne me semble pas valoir le coup.
    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 !

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

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour Philippe et Fabien,

    Juste pour le fun :
    "Stewart GRANGER", de son vrai nom James Lablache STEWART, n'a pas pu prendre comme pseudonyme "James STEWART" car ce nom a été pris pour pseudonyme par... "James STEWART", de son vrai nom James Maitland STEWART.
    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 !

  7. #7
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    Février 2009
    Messages
    5 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 5 220
    Points : 19 452
    Points
    19 452
    Par défaut
    Bonsoir à tous.

    Citation Envoyé par Richard_35 Voir le message
    Si nous commençons à créer des entités (tables, en final) uniquement pour éviter que des attributs simples (champs sans correspondance avec d'autres tables, en final) soient NULL, alors nous n'avons pas fini...
    En effet, si les tables comportent beaucoup de colonnes "facultatives", le schema deviendrait très vite lourd ...

    Citation Envoyé par Richard_35 Voir le message
    Point 1 :De mon point de vue, dans ton cas, la séparation de ces dates en 3 colonnes se justifie amplement (argument commun entre toi et SQLPro).
    La question est donc : est-il admissible que ces trois colonnes puissent être de valeur NULL ?
    ==> à mon sens, oui. La cohérence de la saisie peut être assurée par une fonction traitant les différents cas de saisie/non-saisie.
    Dans ce cas, l'idéale serait d'avoir un identifiant (ou clef primaire) indépendant de ces trois colonnes et éviter les doublons, non pas via l'unicité de la clef, mais via des vérifications par triggers des différentes colonnes ... On peut aussi ne pas vérifier l'unicité d'une date par soucis de simplicité (comme c'est le cas lorsque la date est une donnée portée par une entité du genre Personne, etc) ... mais c'est de la redondance inutile.

    On pourrait aussi avoir trois entités indépendantes et trois associations correspondantes comme ça a déjà été proposé.

    Enfin, une troisième solution qui n'a pas été envisagée c'est d'enregistrer les dates non pas avec une colonne de type DATE mais une colonne en VARCHAR avec un caractère de séparation et un caractère indiquant l'absence d'une donnée. Exemple : X-X-2011, 11-10-2010, X-01-2009, etc. La saisie des dates devrait se faire au niveau de l'application avec un système de listes déroulantes par exemple, pour éviter les mauvaises saisies (on peut aussi contrôler cela via des triggers sinon).

    Si on consent à considérer la date comme donnée unique (non-composée) avec le type DATE, pourquoi ne le serait-elle pas avec un type VARCHAR ou autre ?

    Cordialement,
    Idriss

  8. #8
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je ne comprends pas où tu veux en venir avec tes dates qui serviraient de clé primaire !

    Il est évident qu'une table issue d'une entité type sera munie d'une clé primaire auto-incrémentée.

    =======================

    État de ma réflexion pour le moment...

    1) Dans la table des artistes, une colonne pour le nom d'artiste en entier tel qu'on le donne habituellement (Arletty, François Truffaut, Gérard Depardieu, Louis De Funes, Miou-Miou...) et une colonne pour le classement (Arletty, De Funes Louis, Depardieu Gérard, Miou-Miou, Truffaut François...).
    Ça fait redondance de données mais je ne vois pas comment faire autrement pour le classement.

    2) Une table des vrais noms identifiée relativement à la table des artistes avec une colonne nom et une colonne prénom.

    3) Pour les dates, je réfléchis encore.
    J'ai en fait pas mal de dates facultatives et partielles :
    - dates de naissance et de mort des artistes (je peux ne connaître que l'année) ;
    - date de sortie d'un film (je peux ne connaître que l'année et éventuellement le mois) ;
    - dates de tournage (en général seulement une année... ou plusieurs !) ;
    - dates de création et d'arrêt d'un magazine (date précise ou partielle) ;
    - date de fusion de magazines ;
    - date de parution d'un livre ;
    - dates de début et fin d'une édition d'un festival

    Si j'adopte la rigueur du Relationland si cher à fsmrel et où le bonhomme NULL est interdit de séjour, je vais avoir des dizaines de tables et ça m'effraie un peu.
    En même temps, c'est un sacré exercice de style !

    J'aimerais bien avoir son avis sur la question.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  9. #9
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    Février 2009
    Messages
    5 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 5 220
    Points : 19 452
    Points
    19 452
    Par défaut
    Bonjour.

    Citation Envoyé par CinePhil Voir le message
    Je ne comprends pas où tu veux en venir avec tes dates qui serviraient de clé primaire !

    Il est évident qu'une table issue d'une entité type sera munie d'une clé ...
    Je n'ai pas du être clair dans mon précédant message. Bien entendu la clef devra être indépendante et auto-incrémentée. Je voulais seulement dire qu'il faudrait éventuellement ajouter des traitements supplémentaires (soit au niveau de l'application, soit avec une procédure stockée) pour éviter la redondance des dates.

    Cordialement,
    Idriss.

  10. #10
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Mais les dates n'ont pas besoin d'être uniques ;plusieurs films sortent le même jour et il peut y avoir des jumeaux au cinéma comme dans la vie !

    Si j'adopte cette structure :
    artiste -0,n----avoir----(1,n)- date_naissance

    L'identifiant de la date de naissance sera l'identifiant de l'artiste.
    date_naissance (dna_id_artiste, dna_jour, dna_mois, dna_annee)

    Si par contre j'adopte cette structure :
    artiste -0,n-------dater----0,n- type_date

    L'unicité sera contrôlée aussi par la clé primaire double :
    date_artiste (dar_id_artiste, dar_id_type_date, dar_jour, dar_mois, dar_annee)

    Cette dernière solution me plaît pas mal d'ailleurs, à condition d'accepter que les colonnes dar_jour et dar_mois soit nullables, leur marquage à NULL signifiant "inconnu".
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  11. #11
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    Février 2009
    Messages
    5 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 5 220
    Points : 19 452
    Points
    19 452
    Par défaut
    Les dates ne sont pas forcement uniques mais si on les centralise dans une même entité reliée par divers associations (être né, être décédé. sortir, etc), il devient possible d'éviter la redondance. En reprennant ton exemple, deux occurrences de la table film pourraient pointer vers la même occurrence de la table date.

    Par exemple, j'aurais bien vu une procédure stockée comme ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    FONCTION fdate (jour, mois, année)
    DEBUT
        SELECT INTO nb COUNT (*)
        FROM tdate
        WHERE jour = :jour
            AND mois = :mois
            AND annee = :annee
    
        SI nb <= 0 ALORS
            -- On insère la nouvelle occurrence et on récupère l'id
        SINON
            -- On récupère l'id de la première occurrence correspondante
        FIN SI
    
        retourner id
    FIN
    Simple à mettre en place (si le SGBDR le permet) et efficace je pense ... Il suffira s'y faire appel pour renseigner ou mettre à jour les différentes clefs étrangères qui pointent sur cette table.

    Cordialement,
    Idriss

  12. #12
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je ne réponds qu'aujourd'hui car une autre discussion pointe vers la mienne et je ne suis plus sur ce projet personnel depuis plusieurs mois.

    Ta procédure ne fonctionne que pour les dates complètes or j'ai bien mentionné que j'ai potentiellement beaucoup de dates partielles.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  13. #13
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut de l'utilité des NULL... parfois.
    Bonjour,

    Citation Envoyé par CinePhil Voir le message
    pour des besoins de recherche sur ces critères, il me semble que NULL rend les index beaucoup moins efficaces.
    En quoi les index sont moins efficaces ?
    Seules les entrées d'index non nulles sont indexées.

    C'est plus optimal qu'une jointure avec une autre table car l'index fait directement le lien entre la valeur et l'enregistrement recherché alors que passer par une autre table fait le lien valeur -> ID (de cette autre table) puis on doit faire ensuite ID -> enregistrement recherché. Double de ressources. Double de temps.

    Et si l'on veut indexer les NULL (pour faire une recherche de tous les nulls par exemple) , on peut le faire aussi. ce sera probablement toujours meilleur qu'un NOT EXISTS vers une autre table.

    Au contraire, mettre une colonne indexée à NULL peut être un choix d'optimisation.

    Un exemple: une table de commandes avec un flag qui dit si la commande est traitée ou non. La plupart des commandes sont traitées (pas besoin d'index là dessus donc vu la faible selectivité) et on doit par contre rechercher les quelques commandes qu'il reste à traiter.
    Si on met un flag NOT NULL qui prends les valeurs 'Y' ou 'N' alors va être indexé même ce dont on a pas besoin. On a un gros index dont une grande partie est inutile. Alors que si on met NULL pour les commandes déjà traitées, on a un tout petit index qui n'indexe que ce qu'on veut et qui est très performant.

    Citation Envoyé par ok.Idriss Voir le message
    Enfin, une troisième solution qui n'a pas été envisagée c'est d'enregistrer les dates non pas avec une colonne de type DATE mais une colonne en VARCHAR avec un caractère de séparation et un caractère indiquant l'absence d'une donnée. Exemple : X-X-2011, 11-10-2010, X-01-2009, etc.
    Très mauvais pour l'optimiseur qui ne connaît plus les données qu'il traite. Des problèmes de tris ou de comparaison de date. Impossible d'adapter le format de date si on a des utilisateurs internationaux.
    Des solutions ? On pourrait mettre une date + une colonne de précision (jour, mois année). Ou bien 2 dates min et max. Quel que soit le choix, c'est facile de passer de l'un à l'autre avec les fonctions de dates du SGBD. Et on peut trier, comparer, afficher comme on veut,...

    Ça me fait penser à un exemple d'application qui ne voulait pas utiliser des NULL: en anglais
    L'appli permettait de saisir les numéros de plaques d'immatriculation pour envoyer la facture du parking. Lorsqu'une voiture n'avait pas de plaque, le gardien saisissait XXXXXXX.
    Sauf qu'un jour quelqu'un a une une vraie plaque XXXXXXX ... et il a reçu une note de parking de 19000 dollars

    Est-ce qu'il n'aurait pas mieux valu mettre un vrai NULL pour indiquer l'absence d'information ?

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  14. #14
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Bonjour,

    Et quid d'une table de type métadonnée ?

    Je n'ai pas les connaissances pour savoir si c'est pertinent ou non mais ca pourrai résoudre le problème des nulls de Cinephil tout en gardant une structure correct.

    Par exemple :
    t_dates(persone_id, dat_type, dat_val)

    Avec comme pk personne_id, dat_type

    dat_type pourrait prendre 3 valeurs : année, mois, jour.
    Un contrôle serai nécessaire niveau applicatif pour gérer les dates cohérentes.

    Ensuite pour les recherches, (idem contrôle côté applicatif pour limiter le type de recherche), on aurai comme requete :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    select personne_id
    from t_date
    where (dat_type, dat_val) in ((1, 1998), (2, 5), (3, 28))
    group by personne_id
    having count(*) = 3

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

    Informations forums :
    Inscription : Juillet 2007
    Messages : 3 121
    Points : 4 596
    Points
    4 596
    Par défaut
    Bonjour à tous,

    La phrase clé de ces derniers échanges est
    Citation Envoyé par Franck
    Seules les entrées d'index non nulles sont indexées.
    ==> je n'ai pas les compétences nécessaires pour confirmer ou infirmer. Mais, effectivement, Franck, à mon sens, cela remet en cause pas mal de choses : peut-être s'agit-il d'une évolution de certains SGBD qui n'existait donc pas à l'époque des différents ouvrages brillamment cités par Fsmrel ?

    La confirmation ou l'infirmation de cette assertion semblerait conditionner tout le reste (y compris, donc, la dernière proposition de Punkoff).

    De ce point de vue, les avis de CinePhil et de Fsmrel seraient précieux.
    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 !

  16. #16
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je ne suis malheureusement pas (encore) aussi expert en BDD que fsmrel, SQLPro ou que ne semble l'être Franck Pachot. En tout cas, ses interventions enrichissent les discussions auxquelles il participe. J'ai quand même un doute sur ses affirmations quand au comportement des optimiseurs des SGBD, en regard de la longue expérience dont fsmrel nous fait bénéficier au travers de ses longs messages. Peut-être ce que dit Franck Pachot n'est-il applicable que pour le SGBD qu'il pratique quotidiennement : Oracle ?
    J'aimerais bien que SQLPro vienne donner son avis d'expert MS SQL Server. J'ai remarqué en tout cas que dans ses pages, il ne fait pas la guerre aux NULL.

    Pour en revenir à l'avancement du sujet principal de la discussion que j'ai lancée (les dates partielles), la proposition de Punkoff me semble bien lourde ! Un GROUP BY à chaque fois qu'on cherche une donnée sur une date, ouch !

    Comme dit plus haut, ce projet est en sommeil alors il n'y a pas d'urgence mais le débat reste intéressant.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  17. #17
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Effectivement, je pensais surtout aux index B*Tree d'Oracle ou de PostgreSQL qui n'indexent pas les entrées nulles.
    En général, ça n'a pas beaucoup de sens d'indexer une valeur inconnue - mais c'est seulement une généralité. Il y a des cas où ça peut être utile. En fait je pense surtout que le choix qu'ont fait Oracle ou PostgresSQL vient de l'utilisation des index pour l'implémentation des contrainte uniques. D'après la norme SQL, une contrainte d'unicité n'interdit pas d'avoir plusieurs lignes ayant les colonnes toutes nulles. Donc elles n'ont pas vraiment leur place dans un index unique.

    SQL Server et DB2, me semble-t-il, indexent les entrées nulles.
    Mais du coup il ne gèrent pas correctement (ie conformément à la norme SQL) les contraintes uniques.
    Attention, je n'ai pas testé cela sur une version récente... à vérifier.

    Il y a des solutions alternatives sur tous les SGBD sérieux:

    - Sous Oracle on peut quand même indexer une recherche 'IS NOT NULL' très sélective si on le souhaite.
    - SQL Server a encore mieux: les filtered index. On indexer sur une clause WHERE ... IS NOT NULL.
    - DB2 ? j'en sais rien. Si quelqu'un a une idée...

    Bien sûr, il peut arriver qu'il y ait des contraintes d'implémentation sur certaines plateformes qu'on ne puisse pas utiliser une fonctionnalité. Je peux comprendre que pour un SGBD particulier on cherche à éviter des NULL.
    Mais ce n'est pas une raison pour l'interdire à toute le monde à cause d'une plateforme particulière !

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  18. #18
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par pachot Voir le message
    Effectivement, je pensais surtout aux index B*Tree d'Oracle ou de PostgreSQL qui n'indexent pas les entrées nulles.
    Ça c'est intéressant car je compte utiliser Postgresql.
    Ce projet est aussi l'occasion pour moi de monter en compétence sur ce SGBD car au boulot et pour d'autres projets je n'ai utilisé jusqu'à présent que MySQL et depuis peu Oracle.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 !

  19. #19
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Je voudrais rajouter une chose. On voit dans ce forum 'modélisation' des points de vue très différents.
    C'est assez normal car, contrairement aux forums dédiés à une technologie, ici les contextes peuvent être très variés: différents SGBD, différents contextes métiers qui ne peuvent pas être résumés en un post, etc.
    C'est donc intéressant d'avoir tous les points de vue 'en général' pour pouvoir faire son propre choix dans son propre contexte.

    Donc mon conseil, c'est de lire les différents points de vue, mais de ne pas prendre pour argent comptant un avis ou un autre. Pas plus le mien que les autres.

    Par exemple, j'ai précisé ce que je sais des null et des index. Pour Oracle que j'utilise quotidiennement, et pour d'autres SGBD que je connais un peu.

    Mais c'est aussi très facile de tester:
    - créer une table avec une colonne qui a beaucoup de valeurs renseignées et quelques nulls
    - faire un explain plan pour voir si l'index est utilisé

    Et alors, ça permet d'avoir une idée concrète de la réponse dans votre contexte, votre SGBD, votre version du SGBD, avec ses fonctionnalités et ses bugs, vos types de données, votre paramétrage, etc.

    Les discussions permettent de voir toutes les possibilités.
    Mais c'est le test permet de choisir la bonne...

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  20. #20
    Membre habitué
    Homme Profil pro
    Retraité MO
    Inscrit en
    Mai 2008
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Retraité MO
    Secteur : Finance

    Informations forums :
    Inscription : Mai 2008
    Messages : 75
    Points : 136
    Points
    136
    Par défaut
    J'ai eu un problème de date non conforme il y a quelques temps : je devais enregistrer dans l'année donnée le "report total des affaires antérieures non apurées". Impossible de le mettre dans janvier de l'année en cours car j'aurai planté à la première recherche.
    Heureusement ces dates étaient enregistrées sous la forme mois+année en numérique et non sous forme de date. J'ai alors inventé le mois 00, contenant les données en question, et se situant bien évidemment au début de l'année.
    Donc, si je listais mes mois de 1 à 12 j'obtenais mes affaires, mais si je listais l'année j'avais mon vrai total y compris une ligne appelée "antérieurs".

    Cet artifice est-il possible dans un système supposé gérer les dates ?
    On peut aussi imaginer les dates sous la forme "AAAAMMJJ", numérique acceptant les zéros mais pas les nuls, et supportant les tris.

    Note : il y a bien longtemps que je sais calculer les années antérieures à 1900 !
    .db.
    R.BASILE, 1971 : "Il y a mille et un procédés pour accélérer des particules. Le seul véritablement fondamental restant...le carnet de chèques."

Discussions similaires

  1. Maison des artistes pour travailleur déjà en CDI ?
    Par vallica dans le forum Structure
    Réponses: 9
    Dernier message: 04/07/2007, 22h15
  2. Besoin de l'aide des artistes
    Par Alec6 dans le forum Mon site
    Réponses: 4
    Dernier message: 08/06/2007, 11h15
  3. Réponses: 1
    Dernier message: 10/05/2007, 02h47
  4. Modéliser des modèles de documents
    Par raoudi57 dans le forum Débuter
    Réponses: 5
    Dernier message: 10/11/2005, 21h23
  5. Modélisation des systèmes multiagents
    Par IMANE_nadjat dans le forum Intelligence artificielle
    Réponses: 1
    Dernier message: 10/11/2005, 12h00

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