L'ouvrage est orienté vers le développeur, avec le parti pris assumé de (dé)montrer qu'il aurait tout intérêt à laisser PostgreSQL effectuer le maximum de travail pour lui, en utilisant au mieux SQL et les fonctionnalités du SGBD.
C'est un peu plus compliqué que ça je trouve. Il est généralement difficile de tester unitairement une procédure stockée par exemple, l'utilisation des triggers doit être limité à des cas proches de la donnée,... et probablement d'autres choses. À mon humble al faut s'appuyer sur le data store quand :
c'est naturel :
on évite des aller-retour
c'est déjà le moteur qui connait l'information pertinent
c'est complexe de garantir la cohérence
on a un gros volume de données
il vaut mieux déplacer le traitement vers les données que les données vers le traitement
Mais dans le cas général il vaut mieux faire des choses simples dans les data stores : avoir un système complexe qui échange avec un second système complexe ça devient un enfer à tester.
# Utilisation
Posté par barmic 🦦 . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 4.
C'est un peu plus compliqué que ça je trouve. Il est généralement difficile de tester unitairement une procédure stockée par exemple, l'utilisation des triggers doit être limité à des cas proches de la donnée,... et probablement d'autres choses. À mon humble al faut s'appuyer sur le data store quand :
Mais dans le cas général il vaut mieux faire des choses simples dans les data stores : avoir un système complexe qui échange avec un second système complexe ça devient un enfer à tester.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll