Beaucoup de développeurs ne maîtrisent pas bien les possibilités des bases de données. La plus part (architecte applicatif ou un urbaniste compris) considèrent la base de données comme un data stores, c'est-à-dire un simple entrepôt de données.
Je ne sais pas s'il s'agit d'une pique à mon encontre, mais j'utilise le terme data store parce que je ne parle pas de RDBMS, mais de n'importe quel forme de moteur de stockage du système de fichier à l'IMDG (In Memory Data Grid) et non pour le limiter à du stockage de données.
C'est essentiellement la non connaissance des bases de données des développeurs qui pousse à choisir une solution technique côté applicatif. Je ne vois pas d'autres arguments forts à ne pas choisir de faire les traitements de données au plus proche de la base de données. Je suis preneur de tout contre-argument.
Le manque de connaissance est un argument en soit important. Faire des traitements du coté de ton moteur de stockage peut engendrer des effets de bord des fois très subtiles. Par exemple quand tu exécute une fonction dans redis, il faut qu'elle soit pure, car il ne réplique pas les données résultantes, mais exécute la fonction sur chaque nœud. La gestion des transactions peut être un peu différentes.
Mais ce qui me gêne le plus c'est :
la difficulté de tester : on trouve de plus en plus l'usage du js ce qui aide un peu, mais ça ne fait pas tout. Écrire des tests unitaires sur ce code est bien plus compliqué que dans ton code applicatif ;
la gestion des erreurs est plus complexe : à minima tu as une étape de mapping en plus de tes erreurs ce qui augmente encore le risque que ça soit mal fait. Encore une fois c'est complexe à tester. Tu ne peux pas forcément tester ce mapping facilement.
D'un point de vu d'administrateur système, tu as aussi d'autres arguments :
les machines de calcul et les machines de stockage n'ont pas forcément le même profile et tu prévois pas forcément d'être CPU intenssive sur tes machines de base de données. C'est un problème qui est pris en compte par certains comme couchdb qui a des nœuds spécifiques pour le traitement ;
tu peut vouloir être élastique (→ ajouter/supprimer des instances en fonction de la charge) sur ton applicatif et tu l'es rarement sur tes bases de données.
Je ne dis pas qu'il ne faut pas faire de traitement coté données, mais qu'il y a des contre arguments.
[^] # Re: Utilisation
Posté par barmic 🦦 . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 5.
Je ne sais pas s'il s'agit d'une pique à mon encontre, mais j'utilise le terme data store parce que je ne parle pas de RDBMS, mais de n'importe quel forme de moteur de stockage du système de fichier à l'IMDG (In Memory Data Grid) et non pour le limiter à du stockage de données.
Le manque de connaissance est un argument en soit important. Faire des traitements du coté de ton moteur de stockage peut engendrer des effets de bord des fois très subtiles. Par exemple quand tu exécute une fonction dans redis, il faut qu'elle soit pure, car il ne réplique pas les données résultantes, mais exécute la fonction sur chaque nœud. La gestion des transactions peut être un peu différentes.
Mais ce qui me gêne le plus c'est :
D'un point de vu d'administrateur système, tu as aussi d'autres arguments :
Je ne dis pas qu'il ne faut pas faire de traitement coté données, mais qu'il y a des contre arguments.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll