Je ne sais pas s'il s'agit d'une pique à mon encontre...
Aucune intention de piquer qui que ce soit. Le terme me parait trop réducteur pour parler de PostgreSQL.
Au sens d'un moteur de stockage de donnée (fichier ou mémoire), cela me va. Merci pour tes précisions.
la difficulté de tester
L'outillage est peu normalisé, je te l'accorde. Mais ce n'est pas trop compliqué non plus à mettre en oeuvre. Etant proche des données, c'est assez naturel de tester unitairement les différentes phases d'un traitement complexe. Je suis moyennement convaincu par l'argument.
la gestion des erreurs est plus complexe
Le langage PL/pgSQL de PostgreSQL possède une gestion des exceptions ainsi qu'un système de diagnostique (une sorte de stack trace). Il est aussi possible d'utiliser d'autres langages (non spécialisés à la base de données) avec leur avantages et inconvénients.
D'un point de vu d'administrateur système, tu as aussi d'autres arguments...
Merci pour ces contre arguments.
La situation où le volume de données est important + des traitements consommateurs en ressources (CPU et mémoire notamment) est effectivement problématique. La répartition de charge est un vrai casse-tête, encore plus dans un contexte dit élastique. Ce n'est pas non plus d'une facilité enfantine à traiter côté applicatif.
J'ajoute un contre argument (à mes propres arguments):
Dans le cas de calculs complexes, le gain apporté par la couche applicative est d'avoir à disposition des bibliothèques spécialisées dans ces calculs et de gagner à la fois en simplicité de développement et en performance.
[^] # Re: Utilisation
Posté par _seb_ . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 1.
Aucune intention de piquer qui que ce soit. Le terme me parait trop réducteur pour parler de PostgreSQL.
Au sens d'un moteur de stockage de donnée (fichier ou mémoire), cela me va. Merci pour tes précisions.
L'outillage est peu normalisé, je te l'accorde. Mais ce n'est pas trop compliqué non plus à mettre en oeuvre. Etant proche des données, c'est assez naturel de tester unitairement les différentes phases d'un traitement complexe. Je suis moyennement convaincu par l'argument.
Le langage PL/pgSQL de PostgreSQL possède une gestion des exceptions ainsi qu'un système de diagnostique (une sorte de stack trace). Il est aussi possible d'utiliser d'autres langages (non spécialisés à la base de données) avec leur avantages et inconvénients.
Merci pour ces contre arguments.
La situation où le volume de données est important + des traitements consommateurs en ressources (CPU et mémoire notamment) est effectivement problématique. La répartition de charge est un vrai casse-tête, encore plus dans un contexte dit élastique. Ce n'est pas non plus d'une facilité enfantine à traiter côté applicatif.
J'ajoute un contre argument (à mes propres arguments):
Dans le cas de calculs complexes, le gain apporté par la couche applicative est d'avoir à disposition des bibliothèques spécialisées dans ces calculs et de gagner à la fois en simplicité de développement et en performance.