Vous n'êtes pas identifié(e).
Pages : 1
Bonsoir à tous,
Alors voila, pour un projet j'ai mis en place sur postgreSQL une base de données avec de l'héritage et des contraintes sur mes tables.
J'ai une table parent MEMBRES et deux tables filles JOUEURS et ADMINS. Les tables fille n'héritent pas des caractéristiques de la tables mère sauf la clé primaire (qui est donc une clé étrangère en référence a MEMBRES).
Je souhaitais savoir comment faire pour ajouter une ligne dans la table JOUEURS sans pour autant devoir d'abord faire une INSERT sur la table MEMBRES, puis récupéré l'id inséré (Auto-incrément) puis une deuxième INSERT INTO sur JOUEURS en indiquant ce même id en clé primaire.
J'ai entendu parlé des vues mais je me demande comment faire pour mettre tout ça en place.
J'ai crée ma vue MEMBRES_JOUEURS qui est une jointures des deux, mais pour pouvoir faire un INSERT, il me faut déclaré des règles et la je ne sais pas comment m'y prendre.
HELP
Merci de votre aide !
Hors ligne
Les tables fille n'héritent pas des caractéristiques de la tables mère sauf la clé primaire
Pas de chance, la clé primaire ne s'hérite pas.
Je souhaitais savoir comment faire pour ajouter une ligne dans la table JOUEURS sans pour autant devoir d'abord faire une INSERT sur la table MEMBRES, puis récupéré l'id inséré (Auto-incrément) puis une deuxième INSERT INTO sur JOUEURS en indiquant ce même id en clé primaire.
Pour insérer une ligne dans la table joueurs, faites un INSERT dessus. Pour récupérer l'identifiant, la clause RETURNING est utilisable. Et la suite n'est pas clair du tout donc je ne pourrais pas y répondre.
Guillaume.
Hors ligne
je vais reformuler pour que ça soit plus clair :
MEMBRES { id_membre, pseudo, mail, password }
JOUEURS {id_membre (en reference a MEMBRE.id_membre), points, grade}
Comment utilisé les vue afin de faire une insertion sur JOUEUR sans passer par 2 INSERT ( le premier sur MEMBRES, le deuxieme sur JOUEURS)
Désolé, j'avoue avoir été un peu compliqué avant, mais merci de m'aider
Hors ligne
Il suffit de faire un trigger INSTEAD OF INSERT sur la vue et de gérer les insertions de deux tables dans le trigger.
Ainsi vu du côté client vous ne faites qu'un seul INSERT directement sur la vue.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pourquoi vouloir utiliser une vue ? créez simplement un trigger sur les INSERT dans JOUEURS. Le trigger fera automatiquement l'insertion dans membres via une procédure stockée qui sera déclenchée par ce trigger.
Guillaume.
Hors ligne
Il est vrai qu'avec un trigger BEFORE c'est possible. Néanmoins il est toujours plus intéressant d'accéder aux données d'une base par des vues et le moins possible directement par les tables. Ceci pour des raisons diverses comme la facilité de refactoring des bases ou la meilleures réutilisation des plans de requête.
A +
Dernière modification par SQLpro (14/06/2011 10:41:48)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Que ce soit plus intéressant certaines fois, c'est possible. Toujours, c'est exagéré.
Bref, de toute façon, avant la 9.1, il n'est pas possible de coller des triggers sur les vues avec PostgreSQL. Il est possible d'y mettre des règles mais vu la grande facilité à ne pas les coder correctement, les triggers sont la seule solution conseillable.
Guillaume.
Hors ligne
Guillaume, pas exagéré !!! Vécu... 10 ans d'audit... 15 ans de BD et toujours les mêmes erreurs au final, l'absence du MED (Modèle Externe de Données) avec ses vues !
Par exemple quand on arrive à une table sensible dans une application vieillissante dont la clef est composée de 5 colonnes avec du varchar, qui pose 80% des problèmes de perf, et que l'on dit au client : la solution est de restructurer votre table avec une seule colonne clef et que cela impacte 30% du code applicatif parce que aucune vue n'a été créé.... Moi je me marre !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Le problème initial de ton client, c'est d'avoir une clé de 5 colonnes. Et ajouter une vue ne va pas transformer d'un coup de baguette magique sa clef de cinq colonnes en une clé d'une colonne. Utiliser une vue pourrait faciliter le passage à une clé de une colonne, ça ne changera rien au reste.
Guillaume.
Hors ligne
S'il avait utilisé une vue dès le départ, il n'y aurait eu aucun impact sur le code client lors du refactoring de la table....
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pages : 1
