Discussion :

[kervoaz]

Bonjour,

je me pose la question de savoir si faire un moteur de règles en PL/SQL est une solution viable.
Par moteur de regles, j'entends :
-un traitement complexe
-utilisé par de nombreux utilisateurs
-nombreux paramètres en entrée
-utilise des règles (pouvant évoluées ponctuellement)
-utilise des grandes tables contenant les données de référence

-->typiquement le calcul d'un devis suivant différentes hypothèses.

En PL/SQL chaque session va avoir une copie de ce moteur(=plusieurs packages) -> consommation de mémoire.

Je pense qu'il doit y avoir certaines limites où une autre architecture(Java, C+, thread,..) s'impose?

Avez vous une opinion ou un retour d'experience sur ce sujet?

Merci

[SheikYerbouti]

Bonjour,

J'ai souvenir d'avoir réalisé un tel mécanisme, servant à établir des devis d'assurance. Il n'y a guère de limitations concernant le PL/SQL, car il est modulaire, et les fonctions et procédures peuvent être regroupées en package.
L'avantage est que ledit moteur alimente ensuite n'importe quel type d'interface (Forms,PL/SQL,Reports,Java,JSP,Deplhi,etc...)

[kervoaz]

merci pour ta réponse.

Cependant je me dis que c'est dommage d'avoir 1 copie du traitement par user, chargé, déchargé suivant l'utilisation mémoire alors que le traitement est finalement unique pour tous les users.
Est ce qu'une architecture où le programme(ou plusieurs instanace de ce programme) reside en memoire ne serait pas plus pertinente pour la scalabilté?

[SheikYerbouti]

Il suffit de faire un GRANT EXECUTE sur les autres users afin que tous utilisent la même source.
De plus, vous pouvez effectivement forcer le code du package à s'installer en mémoire. (voir dbms_shared_pool.keep())

[mnitu]

...
Cependant je me dis que c'est dommage d'avoir 1 copie du traitement par user, chargé, déchargé suivant l'utilisation mémoire alors que le traitement est finalement unique pour tous les users.
Est ce qu'une architecture où le programme(ou plusieurs instanace de ce programme) reside en memoire ne serait pas plus pertinente pour la scalabilté?

Il n'y pas 1 copie du traitement par utilisateur.

PL/SQL stored procedures are compiled once and stored in executable form, so procedure calls are quick and efficient. Also, stored procedures, which execute in the server, can be invoked over slow network connections with a single call. That reduces network traffic and improves round-trip response times. Executable code is automatically cached and shared among users. That lowers memory requirements and invocation overhead.

[jmguiche]

Si tu as besoin :

• de bon temps de réponse
• pour une algorithmie riche
• qui fait beaucoup d'échanges avec la base
• fait d'un code maintenable
• développé en un temps raisonnable

tu as besoin de PL (ou de transac si tu est sur sybase ou sqlserver).


En tout cas, d'apres mon experience, java, C++, .NET font systématiquement des choses :

• moins rapides en temps d'éxécution (surtout s'il y a des échanges databases)
• un code complexe et moins maintenable
• un temps de dev plus long.

[kervoaz]

jmguiche, je suis du même avis mais c'est peut être que dans le forum PL/SQL on est moins objectif

Pour ce qui est du partage du code, il me faudrait des eclaircissements:
Si ce moteur est dans un schema à partir duquel les users ont les droits execute, comment va etre chargé les packages du moteur?

Merci

[mnitu]

...
Pour ce qui est du partage du code, il me faudrait des eclaircissements:
Si ce moteur est dans un schema à partir duquel les users ont les droits execute, comment va etre chargé les packages du moteur?

Merci

Désolé, mais je ne vois pas exactement ce que tu veux connaître; peux tu détailler ?

[jmguiche]

Le PL est réentrant.
http://fr.wikipedia.org/wiki/R%C3%A9entrance !
Il y aura autant de sessions que d'utilisateurs connectés.
Chaque session travaillera sur ses propres données.
"l'executable" ne sera chargé qu'une seule fois en mémoire.

[kervoaz]

Merci effectivement c'etait la notion de réentrant.
Cependant (désolé ) quand tu dis "executable" pour un prog en java, .net , je vois ce que ça représente. Pour du PL qui inclus des objets sql ayant des attributs différents suivants les users, les objets PL ont eux mêmes des privileges differents, la notion d'executable n'est plus aussi claire pour moi.

Je peux voir la distinction entre exécution SQL et PL/SQL traitée par des "runtime" différents. Le code d'un package est il toujours une seule fois en memoire et partagé par tous les users meme s'ils ont des priviléges differents?

Dans les doc Oracle, je ne suis pas tombé sur une explication limpide.

Merci

[jmguiche]

Oui, le code, tout comme les curseurs sql, sont présent une seule fois et partagés. Seules les données propres à chaque user ne le sont pas (encore une veine).

[hellmaster78]

Bonjour,

J'ai souri quand j'ai vu le titre du post, car j'ai posté un message hier (cf. Différence entre l'execution d'une procédure en test (mode debug) et l'exec normale), et les procédures en question était un moteur de calcul traitant des règles.

Donc j'ai a peu prés les même contraintes (traitement complexe, gros volumes de données, exécution distincte par utilisateur), et je peux te dire que PL/SQL donne entière satisfaction.

Aprés je ne connais pas l'architecture finale de ton application. L'important est de modéliser la gestion des tes règles de façon à ne pas les coder en dure en PL!

J'ai fait quelques tests dans un langage de programmation, et le temps de réponse n'a rien à voir, car les drivers ODBC ou autres ralentissent énormément les traitements.

[kervoaz]

merci pour vos reponses.
Pour être complet, le moteur existe déjà mais connait des problèmes de perf.
J'ai bien quelques pistes pour optimiser mais on se demandait si une autre architecture ne serait pas plus perenne et plus scalable:
En vrac, déplacement du traitement sur l'AS ou un serveur dédié, faire plusieurs thread, pinné le code en memoire, faire du precalcul sur les données, utilisé un langage optimisé pour les calculs en mémoire(C, C++), utiliser un cache applicatif,...

Cdt