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 :

Relation à l'envers : c'est moi qui suis limité, ou l'auteur qui est cinglé ?


Sujet :

Schéma

  1. #1
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut Relation à l'envers : c'est moi qui suis limité, ou l'auteur qui est cinglé ?
    Bonjour,

    Je viens vers vous, car je travaille sur un outil qui me laisse de plus en plus perplexe.

    Il s'agit d'un logiciel éditeur. J'essaie de mettre en place certaines fonctionnalités, non sans mal, et j'ai vraiment du mal avec certains choix des développeurs.

    Vu que je ne peux me résoudre à admettre qu'ils sont complètement 3 lettres (enfin, 4 au pluriel) je me dis que c'est peut-être moi qui ai raté un wagon... Dénormalisation ?

    Voici l'exemple qui m'afflige le plus.

    J'ai une entité "produit".
    Une autre entité "texte".

    Bon, déjà, c'est un peu bancal, car "texte" contient des traduction d'un peu tout et n'importe quoi, avec différentes méthodes pour faire les relations... selon les entités avec lesquelles elle est liée.

    Au niveau table, voici les colonnes :

    PRODUIT
    ----------
    ID (PK)
    NOM (langue de base)
    TEXTE_ID => FK vers TEXTE (ID2)


    TEXTE
    -------
    ID (PK)
    LANGUE_ID (PK)
    ID2 FK vers TEXTE (ID)
    TRADUCTION

    Evidement, les FK sont purement logiques, niveau base de données, elles n'existent pas (et ne pourraient de toute façon pas, puisque ni TEXTE.ID ni TEXTE.ID2 ne sont uniques et encore moins PK).

    Et niveau données ce que ça donne, par exemple :

    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
    Produit :
    ID NOM     TEXTE_ID
    1  Voiture 1
    2  Bateau  3
    3  Avion   4
    
    Texte :
    ID LANGUE_ID ID2 TRADUCTION
    1  1         1   Voiture
    2  2         1   Car
    3  2         3   Boat
    4  1         4   Avion
    5  1         3   Navire
    6  2         4   Avion
    Explication.

    Lorsqu'on crée un produit, aucune traduction n'est créée. Le "TEXTE_ID" reste à NULL. (déjà, nawak niveau 1FN)
    Ensuite, lorsqu'on crée la première traduction, QUELLE QUE SOIT LA LANGUE, TEXTE.ID prend la prochaine valeur du compteur de la table, et TEXTE.ID2 prend la même valeur. PRODUIT.TEXTE_ID prend alors la même valeur que TEXTE.ID2

    Ensuite, lors des traductions suivantes, pour le même article, TEXTE.ID prend les valeurs suivantes du compteur de la table, et TEXTE.ID2 prend comme valeur PRODUIT.TEXTE_ID

    D'un point de vue performance (index) j'imagine comprendre, partiellement, le voeux du développeur... Un index sur TEXTE.ID2 permet de retrouver les textes associés à un produit en une simple lecture d'index.

    Ok...

    Mais pourquoi ne pas avoir fait :

    PRODUIT
    ----------
    ID (PK)
    NOM (langue de base)


    TEXTE
    -------
    ID (PK)
    LANGUE_ID (PK)
    ENTITE_NOM
    ENTITE_ID (FK logique)
    TRADUCTION

    Ainsi :
    ENTITE_NOM contiendrait "PRODUIT" pour les traductions d'articles.
    Et ENTITE_ID contiendrait l'ID du produit traduit.
    Et un bête index unique sur ENTITE_NOM, ENTITE_ID, LANGUE_ID permettait de faire la même chose, avec un modèle, à défaut d'être parfaitement 1FN, non seulement plus lisible (pas de recopie d'ID dans tous les sens, d'auto-jointures, etc.) mais surtout plus intuitif, et très certainement plus performant.

    Ou si j'ai raté un truc ?
    On ne jouit bien que de ce qu’on partage.

  2. #2
    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 pourquoi ne pas avoir fait :

    PRODUIT
    ----------
    ID (PK)
    NOM (langue de base)


    TEXTE
    -------
    ID (PK)
    LANGUE_ID (PK)
    ENTITE_NOM
    ENTITE_ID (FK logique)
    TRADUCTION
    Ça voudrait dire que l'entité-type TEXTE pourrait être associée pour certaines lignes à PRODUIT, pour d'autres à une autre entité-type... Ce qui n'est pas du tout bon puisque, alors, la clé étrangère ENTITE_ID ne pourrait pas en être une puisqu'elle référencerait plusieurs tables.

    Au niveau table, voici les colonnes :

    PRODUIT
    ----------
    ID (PK)
    NOM (langue de base)
    TEXTE_ID => FK vers TEXTE (ID2)


    TEXTE
    -------
    ID (PK)
    LANGUE_ID (PK)
    ID2 FK vers TEXTE (ID)
    TRADUCTION
    J'en déduis donc le MCD suivant :

    LANGUE -0,n----concerner----1,1----|
    traduire----------------------------1,n- TEXTE -1,n----associer----1,1- PRODUIT
    |--------------------------------------1,1-------|

    C'est effectivement biscornu !
    Il eut été plus simple de faire ce MCD :
    LANGUE -0,n----concerner----1,1- TEXTE -1,1----traduire----0,n- PRODUIT
    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 !

  3. #3
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Pour le premier point, c'est effectivement pour ça que je parle de "FK logique", c'est à dire impossible à modéliser côté SQL, mais éventuellement des contraintes par trigger, ou dans le code de l'application.

    Disons que ma suggestion n'est pas de réécrire toute l'application, mais la solution qui m'aurait paru évidente avec leur modèle actuel (la table TEXTE est bien "liée" potentiellement à toutes les tables, parfois sous cette forme, parfois avec d'autres méthodes encore plus biscornues, que je n'ai toujours pas réussi à comprendre (opération du saint d'esprit ?).

    Et pour le second point, c'est effectivement à cette conclusion que j'arrive. Du coup, je me demande s'il y a une raison technique/sémantique/logique/jenesaisquoiique à la solution qu'ils ont adopté, ou s'ils ont simplement laissé un stagiaire autiste trisomique faire le MCD ?
    On ne jouit bien que de ce qu’on partage.

  4. #4
    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
    Du coup, je me demande s'il y a une raison technique/sémantique/logique/jenesaisquoiique à la solution qu'ils ont adopté, ou s'ils ont simplement laissé un stagiaire autiste trisomique faire le MCD ?
    Je pencherais pour le stagiaire trisomique !

    Je n'ai pas encore trouvé une seule application, parmi celles que j'utilise professionnellement, qui ait un modèle de données normalisé. La plupart ont même des modèles de données pourris. Il nous faut malheureusement souvent faire avec.

    Mais reconnaissons aussi que ce n'est pas toujours évident, surtout quand une application évolue et qu'on ne peut pas remettre en cause tout le modèle de données existant.
    Même pour une application nouvelle, il faut parfois avoir un degré d'abstraction supplémentaire. J'ai développé une application de paiement en ligne qui utilise Paybox. La première utilisation est pour un domaine précis - le paiement des frais de scolarité - mais mon chef m'a demandé d'imaginer qu'on pourrait aussi utiliser la partie paiement en ligne pour d'autres choses dans le futur, telle qu'une inscription à un colloque organisé par l'école par exemple. J'ai donc modélisé séparément la partie transaction financière Paybox et la partie échéance de paiement des frais de scolarité avec une association (et donc une table associative) entre les deux parties du modèle. Lorsque nous développerons l'application des colloques, il suffira de modéliser seulement la partie colloque et de l'associer à la partie transaction financière qui n'aura pas besoin de modification.
    Et même là, si j'avais voulu être vraiment clean, j'aurais fait un schéma de BDD pour les transactions et un autre pour les frais de scolarité alors que pour gagner du temps j'ai tout mis dans le même.
    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 !

Discussions similaires

  1. XE8 Les petites choses qui m'énervent en mode Design , c'est moi ou ?
    Par SergioMaster dans le forum Composants FMX
    Réponses: 4
    Dernier message: 10/06/2015, 17h59
  2. [PhpPgAdmin] c'est lui qui bogue ou c'est moi ?
    Par Chauve souris dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 28/11/2005, 17h30

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