Discussion :

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

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.

[SQLpro]

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 +

[cryptom]

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.

[SQLpro]

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 +

[cryptom]

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

[alassanediakite]

Salut

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

[cryptom]

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

[cryptom]

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 ?

[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 !

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 :


A +

[alassanediakite]

Salut

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

[cryptom]

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.