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.

Exemple :

Code:

---

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:

---

1 2 3

INSERT INTO T_EQUIPEMENT_EQP DEFAULT VALUES;   INSERT INTO T_PERCEUSE_PCS SELECT lastval(), 'Makita';

---

A +

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.

Citation:

---

Envoyé par cryptom

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 +

Citation:

---

Envoyé par SQLpro

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...

Salut

Citation:

---

Envoyé par cryptom

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 .
Par ailleurs il faut utiliser la version 2.1 de PgAdmin 4. Les versions antérieurs de PgAdmin 4 sont trop bugués.
@+

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...).

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:

---

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:

---

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:

---

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 ?

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:

---

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 :
Pièce jointe 351582

A +

Salut

Citation:

---

Envoyé par SQLpro

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.
@+

Citation:

---

Envoyé par SQLpro

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.

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.

Citation:

---

Envoyé par cryptom

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.