Discussion :

[randriano]

Bonjour,

La plupart de nos calculs sont encore traités sous PL SQL (la base de données est ancienne : Oracle 9i).
Le PL SQL nous semble obsolète et pas optimal pour une bonne performance, on aimerait migrer cette logique applicative vers le backend Java Spring Boot.

Est-ce que ça se fait ? Racontez nous vos expériences dans ce sens. Merci

[gervais.b]

Bonjour,

C'est étonnant, à priori ce serait plutôt l'inverse, on déplace les calculs au plus prêt de la donnée pour bénéficier de toutes les optimisations du moteur de BDD. Mais je suppose que ça doit dépendre des "calculs" qui sont faits. Pourquoi est-ce que celà ne se ferait pas ?


Nous avions quelques procédures stockées (MsSQL) assez compliquées et buguées. Après avoir fait plusieurs itérations à préparer le travail dans notre backend pour éviter les bugs, nous avons finalement rétro analysé ces procédures pour les déplacer dans le backend et tout était bien plus clair. Peut-être moins performant mais la performance n'était pas notre problème dans ce cas et nous n'avons rien remarqué.
L'avantage était surtout que tous les développeurs avaient les capacités de lire et de comprendre l'entièreté du code, il n'y avait plus de code obscur disséminé dans une série de scripts de migrations. Mais aussi d'adapter tout ce code (toute l'équipe n'avait pas les compétences MsSQL nécessaires).

La plus grande question était de savoir ou placer cette logique; dans les DAO, repository, services, classes dédiées ?
Beaucoup de ce code était de la validation de "contraintes" (est-ce qu'une valeur existe bien dans une table avant d'insérer dans une autre) on à donc déplacé tout celà à côté de la validation. Pour le reste c'était au cas par cas mais il me semble que c'était quelques règles business que l'on à déplacé dans les services.

[randriano]

Merci gervais.b pour ce partage

Pour notre cas, 70% des procédures stockées que l'on compte déplacer vers le backend ne sont pas des accès base de données mais des logiques applicatives. Et même les 30% restants sont des accès base mais un SELECT d'une seule ligne.

Nous préférons faire les analyses de données non pas avec des curseurs PL SQL mais via ORM côté applicatif !

[gervais.b]

Nous préférons faire les analyses de données non pas avec des curseurs PL SQL mais via ORM côté applicatif !

En effet, vous êtes dans un cas similaire à celui expliqué avant. La logique applicative devrait être, comme son nom l'indique, dans l'applicatif (En considèrant la BDD comme étant une dépendance en dehors de l'application).

[andry.aime]

Bonjour,

C'est étonnant, à priori ce serait plutôt l'inverse, on déplace les calculs au plus prêt de la donnée pour bénéficier de toutes les optimisations du moteur de BDD.

Cela permet aussi de réduire les ressources mémoire et réseau utilisés, et de centraliser les calculs.
Par contre il faut voir aussi la complexité sur la maintenance et la limitation des procédures stockées, qu'il y a aussi des logiques métiers qui sont éphémères, dans ces cas les mettres dans l'applicatif est préférable.

Coté technologie, certe Spring est devenu standard de facto, par contre JEE qui est maintenant Jakarta EE est bien avancé que je couple avec apache deltaspike (data module pour le repository), la plupart des fournisseurs de conteneur ont des plugins maven avec la possibilité de rechargement à chaud pour les dev et une version embarquées pour une application standalone. Il y a aussi les projets quarkus, micronaut et eclipse microprofile.

A+.

[randriano]

Donnez moi un argument où il est idéal d'utiliser le PL SQL au lieu de mettre dans la couche applicative ?

[gervais.b]

Et bien on vous l'a dit. Dans le cas ou la performance est éssentielle et ou les calculs sont sur la donnée. PL-SQL sera plus efficace que de sortir les données pour les traiter dans l'applicatif. Mais, j'estime que c'est une solution de dernier recours. Je partage votre envie de tout sortir ;-D

[andry.aime]

Bonjour,

Exemples:
Quand le calcul nécessite une grande quantité de données, éviter de remonter des miliers de lignes vers l'application par exemple.
Quand un traitement nécessite plusieurs aller-retour application - bdd, surtout sur les traitements volumineux.
Quand un traitement a besoin plusieurs verrous à la fois.

A+.

[randriano]

Bonjour,

Exemples:
Quand le calcul nécessite une grande quantité de données, éviter de remonter des miliers de lignes vers l'application par exemple.
Quand un traitement nécessite plusieurs aller-retour application - bdd, surtout sur les traitements volumineux.
Quand un traitement a besoin plusieurs verrous à la fois.

A+.

Got it.