Bonjour,
Quel est l’intérêt du PL/SQL face à java pour procédure et les triggers dans Oracle 11.
Voir lien pour info
Version imprimable
Bonjour,
Quel est l’intérêt du PL/SQL face à java pour procédure et les triggers dans Oracle 11.
Voir lien pour info
Permettez-moi à vous poser la question à l’inverse : quel est l’intérêt du Java face à PL/SQL ? Essayez de nous donner vos arguments.
Personnellement je n'ai codé que du PL/SQL pour des procédures et des triggers sur Oracle.
Les avantages de Java :
- Programmation Orienté Objet
- Capacité a gérer tous les design pattern POO (Interface,Factory,Abstraction...)
- Accès au bibliothèque Java (String,Math...) et au reste du JRE
- Syntaxe Java
- Non propriétaire
- Communauté de support très large (Open source, Oracle, IBM ...)
- Gère les Threads simplement
C’est vrai qu’en ce qui concerne le critère syntaxe Java ça va être assez dure de battre Java :lol:!Citation:
Envoyé par magnus2005
Bon, je pensais en fait à des choses plus terriennes que ça, genre :
vous devez écrire une procédure qui copie les données de la table hr.departements dans la table my_tab_departements. Voilà ma proposition en PL/SQL.
Maintenant propose-moi l’équivalent Java. A propos expliquez moi, en quoi les autres caractéristiques du langage Java feront que la solution Java que vous allez proposer sera meilleure.Code:
2
3
4
5
6
7
8
9
Pour avoir utilisé des procédures java (ftp, envoi d'editions par mail,etc..), je trouve que le java est loin d'être simple à utiliser / maintenir / débugguer.
Les codes erreurs : mouais.. faut parler le java couramment et comprendre les 257 lignes d'erreur.
Les compilations, l'affichage du source sous toad : pas top pour la maintenance.
Les plantages de la base : J'ai une procédure java de récupération ftp qui a planté 2 fois la semaine dernière. Impossible de savoir dans quelle partie, et obligé de faire un kill -9 du process oracle.
Bonjour,
Je ne pense pas qu'il faille comparer ces deux langages, mais plutôt intéresser à leurs différences. Il ne sert à rien d'utiliser Java pour faire ce que le PL/SQL fait aussi bien sinon mieux. Par contre Java peut être intéressant là ou PL/SQL sort de son domaine. Par exemple, PL/SQL est incapable de ramener une liste de fichiers de la machine sur laquelle tourne la BDD.
C'est un exemple, mais il doit en exister bien d'autres.
C'est très bien. Vous avez résumé ce que Tom Kyte dit toujoursCitation:
Envoyé par SheikYerbouti
"Ce que vous pouvez faire en SQL faites le en SQL
Ce que vous ne pouvez pas faire en SQL faites en PL/SQL
Ce que vous ne pouvez pas faire en PL/SQL faites le en Java (stored Procedure)
Ce que vous ne pouvez pas faire en Java faites le en C
Ce que vous ne pouvez pas faire ni en SQL, ni en PL/SQL ni en Java ni en C, alors .......
posez vous la question sur ce que vous voulez faire
"
On y est presque arrivé: listing files with the external table preprocessor in 11g :lol:.Citation:
Envoyé par SheikYerbouti
Merci pour toutes ces informations.
du coup cela m'inspire d'autre question :
Existe il des possibilités en PL/SQL que le Java Oracle Intégré ne peut faire ?
En termes de performance avez vous une idée du surcout de temps de traitement en Java quasi similaire à PL/SQL d'apres vos expériences ?
Le plus important :
Lors d'une transaction si un trigger en Java est déclenché a t'on le même comportement qu'en PL/SQL ?
En clair avons les mêmes garanties en cas d’échec du traitement Java selon vos expériences ?
Un début de réponse
Par des exemples :
http://www.oracle-base.com/articles/misc/plsql-vs-oracle-jvm-speed-comparison-for-mathematical-operations.php
Via la doc Officiel
http://docs.oracle.com/cd/B28359_01/...e.htm#BABCFIIF
Difficile de trouvé des exemples en faveurs du PL/SQL.
Je fais appel à votre sagacité
En terme de performances le java est largement devant le PL/SQL quelque soit les cas de figure ce qui confirme bien les théories énoncé dans la documentation Oracle
http://www.itmaybeahack.com/homepage/iblog/architecture/C465799452/E20070322201220/index.html
Conclusion de l'article :
PL/SQL Java
24 sec. 7.7 sec.
Je reviens sur la citation suivante
Aujourd'hui en 2013 apres :Citation:
C'est très bien. Vous avez résumé ce que Tom Kyte dit toujours
"Ce que vous pouvez faire en SQL faites le en SQL
Ce que vous ne pouvez pas faire en SQL faites en PL/SQL
Ce que vous ne pouvez pas faire en PL/SQL faites le en Java (stored Procedure)
Ce que vous ne pouvez pas faire en Java faites le en C
Ce que vous ne pouvez pas faire ni en SQL, ni en PL/SQL ni en Java ni en C, alors .......
posez vous la question sur ce que vous voulez faire
"
- Lecture de la doc Oracle Database 11
- Test perso
- Lecture des test tiers
pour moi cela devient
- Ce que vous pouvez faire en SQL faites le en SQL
- Ce que vous ne pouvez pas faire en SQL faites le en Java
- Vous pouvez tout faire en Java.
Le deuxieme conclusion du test suivant
http://www.itmaybeahack.com/homepage/iblog/architecture/C465799452/E20070322201220/index.html
Si finalement si vous rechercher de pure performance avant tout
faite tout en Full Java via des HashMap :
Algorithm Java Python
Pure SQL 7.8 sec. 31 sec.
One Dictionary 3.5 sec. 12.5 sec.
Salut,
Il est rigolo ton lien :
http://www.itmaybeahack.com/homepage...220/index.html
Il fait un test avec du SQL pseudo codé en java : pour ces lookups, on n'a pas la moindre idée du plan d'exécution.
Je ne remettrait pas en cause à priori que tel algo spécifique java soit "plus rapide" (dans quelles conditions exactes ?) que son pendant (PL/)SQL... mais quand je vois un java guy présenter une démarche scientifiquement aussi faible, je n'y accorde aucun crédit.
Tiens à titre de comparaison ton autre lien, où c'est un Oracle guy qui fait le test, il se pose au minimum la question :
Tu noteras également que son premier test était biaisé... le java guy à la place ce serait arrêté là et aurais "V'ai gagnéééé".Citation:
Does this mean that you should rewrite all your PL/SQL to Java? No. We've not taken into account database interaction, which is afterall what PL/SQL is for, and we've also not tested the scalability or impact of multiple users on the Oracle JVM. I've avoided the issue of native compilation, since both PL/SQL and Java can be natively compiled. I just thought it was interesting.
Maintenant, hors de l'aspect performance, je peux juste donner mon à priori :
Pour des traitements classiques comme j'ai pu en recontrer en 7 ans dans l'informatique de gestion du secteur bancaire, le (PL/)SQL suffit dans la plupart des cas.
Et dans ces cas simples ou moyennement simples, cf l'exemple de Mnitu: c'est beaucoup plus facile à comprendre, à maintenir.
Pour faire de l'IA, le Java est certainement plus approprié, je suis d'accord. Mais en informatique de gestion, coder une usine à gaz super classe qui te permet de réaliser 1000% des besoins réels, et dont la flexibilité se rentabilise sur 15 ans, alors que l'appli sera probablement migrée bien avant... comment dire ?
Cela dit, se problème là est plus global qu'une question de java ou autre langage : je vois régulièrement des implémentations insupportables en PL/SQL, où tout passe par des collections. Du coup, pour le simple exemple de Mnitu, on peut arriver à une centaine de lignes de codes (bulk collect, for all, ...).
Et là, fait amusant : à force de faire joujou avec des gadgets et faire un code à s'arracher les cheveux, on rencontre toute une foulitude de traitements au temps d'exécution catastrophiques sur des trucs tout cons du genre "Mon super algo en n log(n) au lieu de n² traite 100 fois trop de lignes parce que je suis une bille en SQL"
.
D'où la question : dans le monde réel, est-il plus important de maîtriser les contentions de bas niveau de l'OS, du RDBMS, de la JVM... ou bien comprendre les besoins métier, comprendre les volumétries, comprendre le desing et l'ordonnancement des traitements, dessiner un modèle de données qui tient la route ?
- Effectivement ce ne sont que des exemples mais je n'ai trouvé personne pas même Oracle pour défendre le PL/SQL
- Le PL/SQL invoque massivement la moteur Java d'Oracle par contre le contraire ne se produit pas
- Le java est beaucoup plus simple PL/SQL ce qui permet de se concentrer sur le fonctionnel plutôt que la technique et de réduire les couts de maintenance car c'est plus simple et plus efficace.(cf Key Features of the Java Language)
- Suivant la doc Oracle la code Java est compilé en natif (=> perf au max) et chaque VM ne prend que 40kb (faible charge mémoire) pourquoi se priver ("N’hésiter pas" nous écrivent les ingénieurs d'Oracle)
- Il est plus important de comprendre les besoins métiers et donc d'avoir des outils simple pour les réaliser Java a été conçu pour cela.
je tire ces conclusions de la doc suivantes qui me semble est être de source sure
Citation de
http://docs.oracle.com/cd/B28359_01/...e.htm#BABCJIED
Citation:
Key Features of the Java Language
The Java language provides certain key features that make it ideal for developing server applications. These features include:
Simplicity
Java is simpler than most other languages that are used to create server applications, because of its consistent enforcement of the object model. The large, standard set of class libraries brings powerful tools to Java developers on all platforms.
Citation:
Java and RDBMS: A Robust Combination
Oracle Database provides Java applications with a dynamic data-processing engine that supports complex queries and different views of the same data. All client requests are assembled as data queries for immediate processing, and query results are generated dynamically.
The combination of Java and Oracle Database helps you to create component-based, network-centric applications that can be easily updated as business needs change. In addition, you can move applications and data stores off the desktop and onto intelligent networks and network-centric servers. More important, you can access those applications and data stores from any client device.
Au début de ma recherche je me posais la question de pourquoi je tombais sur tant de PL/sql sur Oracle et pas beaucoup de Java.Citation:
Performance of Oracle JVM
The performance of Oracle JVM is enhanced by implementing a native compiler. The platform-independent Java bytecodes run on top of a JVM, and JVM interacts with the specific hardware platform. Any time you add levels within software, the performance is degraded. Because Java requires going through an intermediary to interpret the bytecodes, a degree of inefficiency exists for Java applications as compared to applications developed using a platform-dependent language, such as C. To address this issue, several JVM suppliers create native compilers. Native compilers translate Java bytecodes into platform-dependent native code, which eliminates the interpreter step and improves performance.
La seule réponse qu'il m'a été fournie.
Je dirais pour avoir coder avec Java et le PL/sql et tous ceux que je connais qui ont travaillé avec les deux sont unanimes pour dire que faire du PL/sql quand tu peux faire du Java c'est que tu fais le mauvais choix.Citation:
Java je ne connais pas
Dernier point Oracle n'a même pas mise à jour depuis la version 10 des point de doc fondamentaux sur le PL/SQL
comme
http://www.oracle.com/technetwork/da...aq-087606.html
Au final avec Java Oracle DB
- C'est plus simple (la plupart de temps)
- C'est plus performant
- Le PL/SQL est un reliquat du passé
Il y a certain défaut que j'ai constaté à l'usage lors de la création de function SQL en Java mais encore faut il essayé pour en comprendre la problématique
pour répondre à mnitu
C'est du pure SQL il suffit l’exécuter depuis java ou avec SQLJCitation:
-- copie departements into my_tab_departements
INSERT INTO my_tab_departements
SELECT *
FROM hr.departments;
Pour répondre à McM
Oui c'est même mauvais avec Toad, je déconseille Toad (qui par ailleurs est excellent) pour coder Java, Eclipse et plein d'autre IDE le font eux correctement (Oracle propose d'ailleurs des outils pour le faire)Citation:
Les compilations, l'affichage du source sous toad : pas top pour la maintenance.
Je cite juste cette partie, mais c'est en gros ce que je trouve symptomatique dans cette discussion : tu simplifies / généralises trop.Citation:
Envoyé par magnus2005
"C'est plus simple" dépend vraiment de ce que tu veux faire. Typiquement sur l'exemple de Mnitu, l'empactage dans du PL/SQL sera ultra minimaliste (modalité de compilation et de livraison, nombre de classes à créer, librairies à inclure, ...)
J'ai l'impression de troller, mais "java est beaucoup plus simple PL/SQL", c'est super subjectif !
Tiens, tu vois, moi je peux te dire le contraire : "c'est parce que les développeurs java sont généralement des billes en SQL, PL/SQL, et parce qu'ils ont le cerveau tordu, qu'ils trouvent le java plus simple que le PL/SQL".
EDIT : Typiquement dans le genre confusion, tu cites des passages de la doc Oracle qui parlent de créer des server applications en java. Je ne pense pas que qui que ce soit ait envie de faire des "server applications" en PL/SQL !!
Puisqu'on est dans le troll, allons-y
La doc Oracle parle sur une même page des triggers, de pl/sql et de java, on y trouves les paragraphes "avantages de pl/sql", "avantages des triggers" mais pas de traces de "avantages de java"
Vous dites que java produit des résultats 2 fois plus rapidement que pl/sql et c'est vrais, l'étude empirique le montre ... Elle montre aussi que le C est environ 4 fois plus rapide que Java (pour interroger une base Oracle) (cf blg d'Alexei Nedoboi sur le sujet).
Que déduire de ça ? ... Qu'il faudrait réécrire :
- Faites le en SQL
- Si vous ne pouvez pas le faire en SQL faites le en C
J'ai comme un doute
Fin de troll
Je reprends actuellement des procédures écrites en PL/SQL par d'anciens Cobolistes.
Dans la majorité des cas, ce sont des traitements qui mettent en oeuvre trois ou quatre curseurs imbriqués, qui enrichissent ligne à ligne une table temporaire elle-même reprise dans un second traitement de même type... avant de mettre à jour ou ajouter des lignes dans la table finale :roll:
Une fois le tout remis à plat et comparé à la demande fonctionnelle d'origine, cela se réécrit le plus souvent avec un seul et unique MERGE associé à quelques jointures et fonctions analytiques et des temps de traitements divisés par 10, 20 ou mieux (le plus joli : 70h00 en moyenne chaque mois qui passent aujourd'hui en moins d'un quart d'heure ;) Il a fallu revoir le plan d'ordonnancement :mouarf:)
Je n'ose penser à ce que ces personnes auraient fait si on leur avait permis de le faire en Java :aie::aie::cry:
Bonjour,
Le PL/SQL est le langage le plus adapté pour interagir avec les données Oracle. Il gère la dépendance: facile de voir quelle procédure utilise quelle table. Facile de voir ce qui ne compile plus lorsqu'on change une structure de table.
En java c'est à l'exécution qu'on verra le problème.
Le java est probablement le plus adapté aujourd'hui pour le reste (mieux connu, plus de librairies, plus de développeurs moins cher, code réutilisable dans une autre contexte).
Mais si l'on parle de triggers, c'est pour faire du traitement directement lié aux données. Donc PL/SQL. Et comme il est souhaitable de limiter au maximum le code déclenché par les triggers (pour ne pas se retrouver avec plein de choses magiques qui se passent lorsqu'on pense faire seulement un insert/update/delete), les problèmes d'avoir du code PL/SQL (propriétaire, moins connu) sont limités.
Cordialement,
Franck.
Le langage SQL incorporé dans le PL/SQL est un langage ensembliste procédant par modification d'un ensemble de données au sein de transactions... Ni l'un ni l'autre (ensembliste et transaction) ne peuvent être effectuées à travers java ou quelque autre langage itératif que ce soit, sans forcément repasser par le SGBDR et donc obtenir des performances catastrophiques induite par les round-trips....Citation:
Envoyé par magnus2005
A +