IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Spring Boot Java Discussion :

Java Springboot et BD Oracle - Migrer mes pl/sql vers la couche applicative


Sujet :

Spring Boot Java

  1. #1
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 215
    Points : 1 413
    Points
    1 413
    Par défaut Java Springboot et BD Oracle - Migrer mes pl/sql vers la couche applicative
    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
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

  2. #2
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    mai 2020
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : mai 2020
    Messages : 179
    Points : 234
    Points
    234
    Par défaut
    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.

  3. #3
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 215
    Points : 1 413
    Points
    1 413
    Par défaut
    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 !
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

  4. #4
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    mai 2020
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : mai 2020
    Messages : 179
    Points : 234
    Points
    234
    Par défaut
    Citation Envoyé par randriano Voir le message
    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).

  5. #5
    Rédacteur/Modérateur
    Avatar de andry.aime
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    8 365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations forums :
    Inscription : septembre 2007
    Messages : 8 365
    Points : 14 987
    Points
    14 987
    Par défaut
    Bonjour,

    Citation Envoyé par gervais.b Voir le message
    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+.

  6. #6
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 215
    Points : 1 413
    Points
    1 413
    Par défaut
    Donnez moi un argument où il est idéal d'utiliser le PL SQL au lieu de mettre dans la couche applicative ?
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

  7. #7
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    mai 2020
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : mai 2020
    Messages : 179
    Points : 234
    Points
    234
    Par défaut
    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

  8. #8
    Rédacteur/Modérateur
    Avatar de andry.aime
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    8 365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations forums :
    Inscription : septembre 2007
    Messages : 8 365
    Points : 14 987
    Points
    14 987
    Par défaut
    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+.

  9. #9
    Membre expérimenté
    Avatar de randriano
    Homme Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 215
    Points : 1 413
    Points
    1 413
    Par défaut
    Citation Envoyé par andry.aime Voir le message
    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.
    randriano.dvp.com
    Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).

Discussions similaires

  1. Réponses: 2
    Dernier message: 25/04/2008, 19h53
  2. oracle 9i et pl/sql et java
    Par yayamo dans le forum PL/SQL
    Réponses: 1
    Dernier message: 24/05/2007, 09h32
  3. Migrer une BD HyperFile vers oracle
    Par rollins_ng dans le forum WinDev
    Réponses: 2
    Dernier message: 05/07/2006, 13h38
  4. Activer une servlet Java à partir d'outils Oracle
    Par valauga dans le forum Oracle
    Réponses: 1
    Dernier message: 09/03/2006, 16h32
  5. Retourner un resultset java de SQLServer a Oracle
    Par Slash dans le forum Oracle
    Réponses: 10
    Dernier message: 12/08/2005, 11h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo