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

  1. #1
    Membre confirmé
    regroupe de tables simple en une seule génériques
    bonjour,

    je voudrais un avis.

    voilà dans mon système, j'ai une multitude de tables simples ayant la même structure (nn de champs et propriétés) :
    un champ id, un champ nom. un champ desccription explicite

    3 exemples :

    table Civilités
    id, lib_court, lib_long

    table Salles
    id, sal_num, salle_nom

    table Tâches
    id, code_tache, nom tâche

    Et donc plutôt que de créer 30 tables, j'envisage de créer une table générique 'catégorie":
    id
    acronyme
    description
    typologie (soit Civilité, soit Salle, soit Tâche soit X Y Z... )

    que penser de cette idée ? Je souhaite faire cela plutôt qu'avoir à gérer 30 procédures différentes allant du backup au formatage (écran, dev interface,sécurité,logging,workflow,formation)

    Merci de votre opinion.

  2. #2
    Modérateur

    En bref : il vaut mieux conserver les tables.

    Conceptuellement, une civilité n'est pas une catégorie ou une salle.

    La civilité s'associe avec une personne physique :
    Personne_physique -1,1----avoir----0,n- Civilite

    Si vous mélangez des concepts différents dans une seule table - donc si vous transférez les civilités dans une table catégorie, au lieu d'avoir Monsieur Dupont, vous pourriez avoir Réunion Dupont ou Salle 12 Dupont.
    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
    Membre confirmé
    Regrouper de tables simples en une seule générique foure-tout
    bonjour,

    je m'excuse pour les fautes d'orthographe dans le titre du sujet : Regrouper de tables simples en une seule générique

    Je savais qu'en appelant ma table générique "catégorie", on pourrait m'argumenter sur le terme catégorie d'un point de vue sémantique.
    En y réfléchissant, je voudrais plutôt appeler ma table générique "propriétés" ou "attributs" qui me semblent mieux adéquat.

    une civilité est une propriété d'une personne
    une salle est une propriété d'un batiment
    en fait tout passe bien avec ce terme ;-)




    J'ai compté 25 tables dans mon SI n'ayant que un ID, un titre, une description !! Ya même une table "couleurs" (id, code, nom).
    Au mieux sur le plan software, je distribuerais 25 vues (VIEWS basées sur mon champs typologie qui permettra de catégoriser les 25 notions initiales) si les devs ont réellement besoin de séparer les "notions".

    Plus sérieusement, je me questionnais plutôt sur le plan technique , voire performance ensuite. Cette table risque d'être trop solicitée. J'ai considéré ma table "personnes" qui aura besoin de 5 requêtes (5x left join) sur cette table génériques...
    Peut-être qu'au niveau SQL ensuite, avoir un type ENUM de 25 choix est une énormité ou un boulet à performance...? suviant les RGBD...

    à bientôt.

  4. #4
    Modérateur

    Votre idée reste une mauvaise idée !

    J'ai compté 25 tables dans mon SI n'ayant que un ID, un titre, une description !! Ya même une table "couleurs" (id, code, nom).
    Et alors ? Aucun problème !

    Au mieux sur le plan software, je distribuerais 25 vues (VIEWS basées sur mon champs typologie qui permettra de catégoriser les 25 notions initiales)
    ... ou pourquoi faire simple quand on peut faire compliqué !

    Par contre, vous aurez effectivement besoin d'utiliser ces tables dans des vues. PAr exemple, la vue des personnes physiques rassemblera les données des personnes avec leur civilité en clair. Voici par exemple une des miennes :
    Code SQL :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
    17
    18
    19
    20
    21
    CREATE OR REPLACE VIEW v_personne_physique AS
    SELECT p.prs_id pphId,
    	p.prs_nom pphNomUsuel,
    	ph.pph_prenom pphPrenomUsuel,
    	ph.pph_nom_naissance pphNomNaissance,
    	ph.pph_prenom_2 pphPrenom2,
    	ph.pph_prenom_3 pphPrenom3,
        cv.civ_id pphIdCivilite,
        cv.civ_abreviation pphAbrevCivilite,
        cv.civ_libelle pphLibelleCivilite,
    	ph.pph_id_sexe pphidSexe,
    	ph.pph_id_nationalite pphIdNationalite,
    	py.pay_nationalite pphNationalite,
    	ph.pph_id_ville_naissance pphIdVilleNaissance,
    	v1.vil_nom pphVilleNaissance,
    	ph.pph_date_naissance pphDateNaissance
    FROM th_personne_physique_pph ph
    INNER JOIN te_personne_prs p ON p.prs_id = ph.pph_id_personne
    INNER JOIN referentiel.tr_civilite_civ cv ON cv.civ_id = pph_id_civilite
    INNER JOIN referentiel.tr_pays_pay py ON py.pay_id = ph.pph_id_nationalite
    INNER JOIN referentiel.tr_ville_vil v1 ON v1.vil_id = ph.pph_id_ville_naissance;

    Vous voyez que j'ai bien une table des civilités et même une table des sexes.

    si les devs ont réellement besoin de séparer les "notions"
    Évidemment qu'ils en auront besoin ! Donc autant les séparer dès le départ !

    Plus sérieusement, je me questionnais plutôt sur le plan technique , voire performance ensuite. Cette table risque d'être trop sollicitée.
    Effectivement et, de plus, interrogeable de manière inutilement compliquée.

    J'ai considéré ma table "personnes" qui aura besoin de 5 requêtes (5x left join) sur cette table génériques...
    Les jointures ne sont pas en soi un problème mais quitte à faire des jointures, autant que ce soit sur des tables différentes.

    eut-être qu'au niveau SQL ensuite, avoir un type ENUM de 25 choix est une énormité ou un boulet à performance...?
    Évitez absolument les ENUM !

    Bref, vous avez semble t-il à peu près bien modélisé dès le départ ; ne revenez pas en arrière !
    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 !