1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut PGadmin 4 - Postgres 9.6 - Table avec héritage

    Bonjour,
    je n'avais jusque là pas essayé l'héritage, j'essaie de le mettre en pratique avec PgAdmin.

    Dans mon cas :
    - Une table mère "EQUIPEMENTS"
    - Une table enfants "PERCEUSES"

    Si j'ai bien compris le principe : il s'agit :
    De créer la table mère avec un clé primaire (id unique), là c'est ok.
    De créer la table fille en indiquant la table mère, là c'est ok.
    De mettre la clé primaire qui est héritée en clé primaire de l'enfant, a priori ok en paramétrant une contrainte.
    De faire en sorte que cette clé primaire soit aussi clé étrangère, là ça coince.

    Et lorsque j'essaie d'ajouter des enregistrements, pgAdmin ne fait rien...

    pour l'exemple, je n'ai que 2 colonnes , "id" dans la table "EQUIPEMENTS" et "nom" en plus dans la table "PERCEUSES" (l'id étant récupéré automatiquement de la mère).

    Est-ce que vous auriez sous la main, ou en lien, un exemple de création d'héritage dans pgAdmin ?

    Merci d'avance pour vos éclairages.

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 765
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 765
    Points : 41 455
    Points
    41 455
    Billets dans le blog
    1

    Par défaut

    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE T_EQUIPEMENT_EQP
    (EPQ_ID            SERIAL PRIMARY KEY);
     
    CREATE TABLE T_PERCEUSE_PCS
    (EPQ_ID            SERIAL PRIMARY KEY REFERENCES T_EQUIPEMENT_EQP (EPQ_ID),
     PCS_NOM           VARCHAR(32) NOT NULL);
    Ne mettez pas de S à vos nom de table... et distinguez vos colonnes

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    INSERT  INTO T_EQUIPEMENT_EQP DEFAULT VALUES;
     
    INSERT INTO T_PERCEUSE_PCS SELECT lastval(), 'Makita';
    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    C'est vrai qu'il faut que je fasse attention à mes noms de colonnes. Pour le s...

    En l'occurrence, je cherchais à trouver la manipulation avec PgAdmin (l'interface), par forcément le code SQL. Dans l'exemple que vous donnez, il n'y a d'ailleurs pas d'instruction INHERITS, pourquoi ?

    A priori, après quelques tests, il n'y a pas besoin de définir de clé étrangère, postgres a l'air de gérer tout seul l'unicité des identifiants, à partir du moment où il y a héritage.

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 765
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 765
    Points : 41 455
    Points
    41 455
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par cryptom Voir le message
    A priori, après quelques tests, il n'y a pas besoin de définir de clé étrangère...
    Si vous voulez faire de la merde oui ! C'est comme l'airbag la ceinture de sécurité ou l'ABS...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Si vous voulez faire de la merde oui ! C'est comme l'airbag la ceinture de sécurité ou l'ABS...

    A +
    Merci pour cette réponse aussi agréable qu'utile...
    Certains n'ont pas besoin de connaître la mécanique de l'ABS, ou pire, de construire leur propre système à chaque fois qu'ils veulent conduire une voiture...
    Si c'est trop compliqué de rester simple pour vous, ô grand ayatollah du SGBD ! Ne vous penchez donc pas les interrogations d'un ignorant comme moi.
    L'aigreur n'est point bonne pour la pédagogie...

  6. #6
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 277
    Points
    3 277
    Billets dans le blog
    8

    Par défaut

    Salut
    Citation Envoyé par cryptom Voir le message
    Bonjour,
    je n'avais jusque là pas essayé l'héritage, j'essaie de le mettre en pratique avec PgAdmin.

    Dans mon cas :
    - Une table mère "EQUIPEMENTS"
    - Une table enfants "PERCEUSES"

    Si j'ai bien compris le principe : il s'agit :
    De créer la table mère avec un clé primaire (id unique), là c'est ok.
    De créer la table fille en indiquant la table mère, là c'est ok.
    De mettre la clé primaire qui est héritée en clé primaire de l'enfant, a priori ok en paramétrant une contrainte.
    De faire en sorte que cette clé primaire soit aussi clé étrangère, là ça coince.
    L'héritage tel que vous l'utilisez est manuel. La meilleur façon de le mener à bien est d’utiliser une vue qui se substitue à la table héritière (perceuse)...
    • la vue sur une jointure entre les deux tables avec toutes les colonnes des deux tables (la clé primaire de l'héritière n'est pas necessaire serait même de trop)
    • un trigger instead of insert update delete sur la vue qui se charge de dynamiser la vue

    Pour un héritage automatique c'est à dire piloter directement par PostgreSQL voir ici.
    Par ailleurs il faut utiliser la version 2.1 de PgAdmin 4. Les versions antérieurs de PgAdmin 4 sont trop bugués.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    Bonjour,
    merci pour ces indications.
    Pourquoi pas une vue en effet ? Il faudra s'assurer que la table ne soit pas modifiée par ailleurs (ça devrait pouvoir se faire).

    Si je reste sur l'héritage, la question de la clé primaire est un peu obscure pour moi : comportement dans une jointure (appel à la table mère ?), et l'unicité notamment. Je vais faire quelques essais.

    Et merci pour la précisions sur la version de pgAdmin, je suis sur la 2.0, je vais la mettre à jour (des outils bugués donnent raison à notre ami au-dessus...).

  8. #8
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    Bonjour,
    après quelques essais je rencontre un problème, pour faire une vue avec des tables liées filles du même parent.
    Je m'explique :
    Nous avons :
    - Une table mère "EQUIPEMENTS"
    - Une table enfant "PERCEUSES"

    Je rajoute une table enfant de "EQUIPEMENTS" que j'appelle "CABLAGES"

    Je lie "PERCEUSES" avec "CABLAGES" -> Telle perceuse est fournie avec tel cablage.

    Lorsque je fais un SELECT comme suit :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT * FROM "PERCEUSES" as "p"
    LEFT OUTER JOIN "CABLAGES" as "c" ON ("p"."id_cablage" = "c"."eqt_id")
    ça marche sans problème.

    Par contre, lorsque je faire un vue avec cette sélection :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CREATE VIEW VPERCEUSES as
    SELECT * FROM "PERCEUSES" as "p"
    LEFT OUTER JOIN "CABLAGES" as "c" ON ("p"."id_cablage" = "c"."eqt_id")
    J'ai le message d'erreur suivant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    ERROR:  ERREUR:  la colonne « eqt_id » est spécifiée plus d'une fois
     
     
    SQL state: 42701
    ça doit venir certainement du fait que le eqt_id hérité de la mère est présent dans les 2 tables "PERCEUSES" et "CABLAGES", il s'agit en plus de leur clé primaire. Est-ce qu'il faut en conclure que dans la vue on ne peut sélectionner que l'identifiant de PERCEUSES OU celui de CABLAGES, (a condition de tout lister ?) mais pas les 2 ? Du coup, ça peut être gênant...

    Edit :
    C'est peut-être plutôt du au fait que étant les enfants d'une même table, cela revient à une jointure d'EQUIPEMENTS avec elle-même. Y a-t-il une issue ?

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 765
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 765
    Points : 41 455
    Points
    41 455
    Billets dans le blog
    1

    Par défaut

    le SELECT * est TOUJOURS une grosse connerie qui vous pete à la gueule quand on s'y attend pas!!!

    Une table doit avoir des colonnes ayant des noms unique... Sinon, comment voulez vous l'exploiter ? Pour rappel une vue n'est autre qu'un type de table !

    Donc
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    CREATE VIEW VPERCEUSES as
    SELECT p.eqt_id AS eqt_id_racine, c.eqt_id AS eqt_id_fille, ... 
    FROM "PERCEUSES" as p
    LEFT OUTER JOIN "CABLAGES" as c ON p.id_cablage = c.eqt_id
    Et pas besoin de tous ces guilllemets et parenthèses !

    Lisez mon livre sur SQL :
    Nom : Couverture SQL Synthex 4e ed - 500.jpg
Affichages : 96
Taille : 77,8 Ko

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 530
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 530
    Points : 3 277
    Points
    3 277
    Billets dans le blog
    8

    Par défaut

    Salut
    Citation Envoyé par SQLpro Voir le message
    Et pas besoin de tous ces guilllemets et parenthèses !
    Avec PostgreSQL les guillemets sont obligatoire si vous avez créé vos objets avec des noms en majuscules.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  11. #11
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    le SELECT * est TOUJOURS une grosse connerie qui vous pete à la gueule quand on s'y attend pas!!!

    Une table doit avoir des colonnes ayant des noms unique... Sinon, comment voulez vous l'exploiter ? Pour rappel une vue n'est autre qu'un type de table !
    Peut-être pas besoin de tous ces "points d'exclamation"...
    Mais merci pour la réponse, c'est effectivement évident que les noms doivent être distincts.

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2009
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 26
    Points : 16
    Points
    16

    Par défaut

    Je pense avoir eu les réponses à mes interrogations, merci à ceux qui ont donné de leur temps pour le faire.

    Je marque la discussion comme résolue.

  13. #13
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 453
    Points : 7 704
    Points
    7 704
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par cryptom Voir le message
    Peut-être pas besoin de tous ces "points d'exclamation"...
    Mais merci pour la réponse, c'est effectivement évident que les noms doivent être distincts.
    Non seulement ça, mais aussi et surtout, utiliser un SELECT * compromet l'indépendance logique physique et rend du coup la création d'une vue sans grand intérêt !
    Et aussi, mais c'est moins grave, qui dit SELECT * avec une jointure, dit redondance d'informations sur les colonnes de jointure au détriment des performances.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 17/04/2011, 16h30
  2. Droits des tables avec pgAdmin 111
    Par Safaritn dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 20/12/2006, 09h03
  3. [Access] Nom d'une table avec un espace dans SQL
    Par Corsaire dans le forum Langage SQL
    Réponses: 7
    Dernier message: 21/04/2006, 15h50
  4. [syntaxe]Creation table avec nom dynamique
    Par ZuZu dans le forum MS SQL-Server
    Réponses: 6
    Dernier message: 23/09/2004, 18h01
  5. Création de table avec index
    Par Seb7 dans le forum Requêtes
    Réponses: 2
    Dernier message: 10/04/2003, 16h11

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