De la meilleure façon d'appréhender les vues PostgreSQL dans du code [Résolu]

[jMax31]

Bonjour,

C'est mon premier message ici et il est peut-être un peu hors sujet (si vous trouvez que c'est le cas, je m'en excuse par avance), mais j'aimerais quand même avoir l'avis d'experts PostgreSQL sur la question.

Voilà : d'un côté j'ai une base PostgreSQL avec une table et une vue (assez complexe) basée sur cette table, et d'un autre côté j'ai une appli écrite en QtJambi (Qt en Java) qui va utiliser cette base.

Le framework Model/View de Qt permet de définir une QTableModel qui constitue un modèle (au sens MVC) correspondant à une table. A l'utilisation, on modifie les données dans cette QTableModel puis on fait un database().commit() pour répercuter les modifs dans la base. Très pratique.

Bien sûr du point de vue de Qt, les vues PostgreSQL ne présentent aucune différence avec les tables. On peut donc utiliser une vue comme source de données d'une QTableModel. Pas de problème... en tout cas tant qu'on essaie pas de modifier les données. Je n'ai pas osé essayer un commit() sur une vue, mais comme les vues PostgreSQL sont read-only, je suis à peu près sûr du résultat.

Pour pouvoir éditer les données la démarche logique est donc d'utiliser la table comme source de données et non plus la vue. Mais alors pour présenter les données comme dans la vue il faut réécrire dans le code, l'équivalent de toutes les fonctions utilisées dans la vue, et comme j'ai passé pas mal de temps à développer toutes ces fonctions pour construire cette vue, j'aimerais bien éviter d'avoir à me retaper tout le boulot dans le code. D'autant que les premiers tests font apparaitre une chute de perf assez considérable.

Est-ce que vous auriez des idées sur la meilleure façon d'appréhender la question ?

Merci pour toute information à ce sujet.

jMax

[GrandFather]

Bonjour,

D'abord bienvenue sur les forums de Developpez.com, et puis je te rassure, ce n'est absolument pas un HS.

PostgreSQL propose un système qui consiste à pouvoir réécrire une requête SQL avant son exécution selon des règles définies par le développeur. Cela permet notamment de rendre des vues "modifiables", ce qui est théoriquement impossible : on substitue selon les règles un INSERT sur une vue par un INSERT sur des tables. Ce processus est totalement transparent pour le code client, ce qui devrait t'épargner d'avoir à le modifier en profondeur. Les règles se créent avec CREATE RULE.