Discussion :

[nathieb]

Bonjour,

J'ai une expérience sur les vues matérialisées sur Oracle mais je dois les mettre en oeuvre sur postgres.
En lisant la doc, mise à part la notion de Refresh qu'on doit certainement associer à un trigger, il n'est pas fait mention
de cas avec des mises à jour incrémentales, d'ailleur, je trouve peu ou pas d'exemples concrets sur la mise en place.
Si jamais il trâine des liens sur votre bureau ou retour d'expérience, je suis preneur.

Olivier

[SQLpro]

ça n'existe pas la notion de mise à jour incrémentale des vues matérialisée de PostGreSQL. Le refresh recalcule donc tout. Dans les faits les vues matérialisées de PostGreSQL c'est de la daube ! Inutile en production....

A +

[ced]

Bonjour,

Non, pour le moment, la mise à jour incrémentale des vues matérialisées n'est pas encore implémentée dans PostgreSQL.
Un patch est en cours de développement pour l'intégrer dans la prochaine version majeure (v14)...

Il manque certes des fonctionnalités, mais de là à tout qualifier de "daube", il ne faut pas non plus exagérer !

[al1_24]

Il manque certes des fonctionnalités, mais de là à tout qualifier de "daube", il ne faut pas non plus exagérer !

Ne t'arrête pas à ça...
SQLPro est juste un peu binaire. Apparemment, pour lui il semblerait qu'il y a SQL Server d'un côté et des daubes de l'autre.

[SQLpro]

He bien je ne voit aucun intérêt à créer des vues matérialisées qui vont devoir être intégralement recalculées, alors que la requête d'origine, va faire exactement la même chose mais pile au moment voulu, alors qu'avec la méthode proposée par PostGreSQL on a aucune certitude de synchronisation entre le refresh (requête de calcul) et l'envoi du résultat..... Cela va juste encombrer avec un objet de plus et un volume de données inutile la base de données.

Et je revendique ma binarité... n'est pas le propre de l'informatique ?

A +

[nathieb]

Bonjour,

Je ne m'attendais pas à un combat d'égo, je voulais juste avoir des renseignements sur une solution.
Je me dois de ne pas juger, mais de trouver des solutions.
Donc mis à part le refresh, en job ou en trigger, c'est à moi de gérer.

Est-ce que vous avez juste des bonnes pratiques sur la mise en place de telle ou telle solution.

Merci pour vos réponses

Olivier

[nathieb]

Bonjour,

He bien je ne voit aucun intérêt à créer des vues matérialisées qui vont devoir être intégralement recalculées, alors que la requête d'origine, va faire exactement la même chose mais pile au moment voulu, alors qu'avec la méthode proposée par PostGreSQL on a aucune certitude de synchronisation entre le refresh (requête de calcul) et l'envoi du résultat..... Cela va juste encombrer avec un objet de plus et un volume de données inutile la base de données.

Et je revendique ma binarité... n'est pas le propre de l'informatique ?

A +

Plus maintenant, avec l'informatique quantique ... il existe des états
A quantum computer also has bits — but instead of 0 and 1, its quantum bits, or qubits, can represent a 0, 1, or linear combination of both, which is a property known as superposition.

Donc le théorème n'est plus valable

Olivier

[fsmrel]

Tout à fait, Olivier, mais pour faire de l’informatique binaire pré-quantique, on n’a pas besoin d’un ordinateur spécialisé (problème de la décohérence oblige, et la nécessité aujourd’hui d’un froid pas trop éloigné du zéro absolu, et tout ça...). Cela dit, la matérialisation des vues en SQL quantique, même avec une daube quantique (oxymore ) ça devrait décoiffer !