db

PostgreSQL possède une fonctionnalité très pratique : la possibilité d’avoir des vues matérialisées. Contrairement à des vues SQL classiques, qui ont la lourdeur des joitures et autres traitements qu’elles contiennent, la vue matérialisée permet d’avoir le contenu généré par une vue en « dur » comme s’il s’agissait d’une table, avec la vitesse de lecture qui va avec. Voyons comment faire ça avec SQLite



2 min.

Partager l’article Simulation de vues matérialisées avec SQLite sur les réseaux sociaux

Pourquoi ?

Pourquoi faire ça ? SQLite est très rapide en lecture, et ne possède pas de système en natif pour faire des vues matérialisées. Alors ?

Alors il arrive qu’un jour ou l’autre on tombe sur un projet avec des synthèses de données de plus en plus compliquées, dans des vues de plus en plus longues à affichées du fait de l’abondance des jointures et des traitements effectués pour les afficher, même si on a bien géré les indexes.

Comment ?

Le principe est simple. Il suffit de créer une table classique et d’y mettre régulièrement les données d’une vue lourde à afficher.

Dans cette table, on peut y définir des indexes pour accélérer les choses aussi.

À quel moment ?

Là, tout dépand de votre besoin. On peut très bien faire les choses de manière atomique, faisable selon certains cas, soit on fait une mise à jour régulière de la « vue matérialisée ».

C’est de ce dernier cas dont je vais vous parler.

Méthodologie

Comme cette petite astuce dépend d’énormément de facteurs, je ne vous fournis que la méthodologie générale :

  1. Avoir en place un audit des tables qui stocke les ajouts, modifications et suppressions d’éléments.

  2. Avoir une table stockant la date et l’heure de la dernière synchronisation de la vue matérialisée.

  3. Avoir une vue qui regroupe les audits des tables concernées par la vue matérialisée.

  4. Avoir une tâche cron tournant toutes les secondes (ou minutes, heures, selon l’importance est les fréquences de mises à jour, à vous de voir) qui compare la date et l’heure des derniers enregistrements de la vue d’audit par rapport à la table stockant l’état de la dernière synchro.

  5. En fonction du résultat précédant, mettre à jour la table ou non.

Conclusion

Cette petite astuce doit égelement vous mettre la puce à l’oreille : Si la gestion des données est de plus en plus compliquée avec vottre base SQLite, c’est peut-être qu’il est tout simplement temps de changer son fusil d’épaule et de passer à une base de données qui convienne mieux, une vrai base de données. MySQL ou Postgresql (je conseille ce dernier) seraient un bon départ.

Photo de Markus Spiske sur Unsplash