Discussion :

[rvfranck]

Salut,

J'aimerais faire une petite doc sur la POO en Oracle PL/SQL. Y'a t'il déjà un article sur le sujet? Y'a t'il quelqu'un qui travaille sur ce thème?

Merci

[Vincent Rogier]

Salut,

Je ne peux que t'encourager !

C'est effectivement un très bon choix !

[nuke_y]

POO en Pl/SQL ?? C'est possible ?

[Vincent Rogier]

POO en Pl/SQL ?? C'est possible ?

tout à fait !

Il va falloir que tu reprennes tes bouquins et docs sur le PL/SQL..

Oracle a introduit les object avec 8i, la POO avec 9i et a pas mal avancé sur POO avec 11g

Oracle supporte les objects , l'héritage, les méthodes virtuelles, la surcharge de méthodes, constructeurs, ....

He oui !!!!!!

[Vincent Rogier]

un petit exemple pour la forme

un autre exemple

[Vincent Rogier]

Et le lien sur la documentation officielle oracle :
Oracle Database Application Developer's Guide - Object-Relational Features

[rvfranck]

POO en Pl/SQL ?? C'est possible ?

C'est vrai qu'on en parle pas trop... pratiquement jamais sur "notre" site
Moi je compte la faire avec la 11g

[nuke_y]

Dis donc

Ce que je trouve dingue c'est de jamais en avoir seulement entendu parler.

[rvfranck]

Tu parles, c'est vraiment dingue!!!

[jmguiche]

A de rares exceptions près, c'est une technique qui permet de coder en 500 lignes un truc que l'on coderait en 100 si on ne l'utilisait pas.

Génial !

[Vincent Rogier]

A de rares exceptions près, c'est une technique qui permet de coder en 500 lignes un truc que l'on coderait en 100 si on ne l'utilisait pas.

Génial !

ce genre de propos ressemble furieusement aux arguments de certains programmeurs quand les langages orientés objets généralistes ont émergés !


bon un débat peut être lancé

Cela mériterai un nouvelle discussion/sondage/débat à annoncer sur l'index de la rubrique !

[rvfranck]

A de rares exceptions près, c'est une technique qui permet de coder en 500 lignes un truc que l'on coderait en 100 si on ne l'utilisait pas.

Génial !

C'est démotivant ce que tu dis là.

[Vincent Rogier]

C'est démotivant ce que tu dis là.

N'écoutes surtout pas jmquiche

Ses propos sont infondés et si on l'écoutait, personne de ferait de l'objet et n'utiliserait les langages objets et orientés objet...

Oracle 8, il y a plus de 10 ans , a introduit la notion d'objet dans Oracle Database et la POO il y a 8 ans avec 9i.

Certes, les capacités objet de Oracle ont été peu exploitées (pendant des années cela a concerné principalement les domaines géométrique et de géolocalisation).

C'est grâce à cette notion d'objet que Oracle a intégré le XML dans sa base il y a des années.

Comme le SQL ANSI n'est supporte pas la notion d'objet et que la programmation classique SQL n'est pas orienté objet, des frameworks comme hibernate ont été crées pour gérer la translation relationnel / objet...

Oracle propose en natif ce concept avec ses objets.... alors que autres gros acteurs du marché SGBD ne proposent pas grand chose si ce n'est rien..

Et de plus les tables d'objets sont manipulables directement sans passer par le moteur SQL ! Ce qui augmente les perfs ! Il est possible de manipuler les objets oracle en SQL mais aussi directement et Oracle assure que l'accès natif direct est beaucoup plus performant.

Oracle a donc introduit la POO au sein de sa base en ajoutant un couche orienté objet supportant l'héritage, le polymorphisme, l'encapsulation, etc....

Tu connais beaucoup de de gros SGBD permettant de déclarer des objet avec des constructeurs et de méthodes virtuelles et/ou surchargées ?

Comme il y a peu de ressources sur la POO Oracle, je te suis à 100% dans ton idée de tuto !

Et n'écoutes pas certains réfractaires hostiles à la POO.

La syntaxe des objets Oracle est étroitement liés à celle du PL/SQL et de ADA... Certe c'est pas la syntaxe la plus concise possible mais ce n'est pas pour autant que c'est pas bien...

L'implémentation POO dans Oracle a été précursive et évolue à chaque release de Oracle Database !

Pour ce tuto, tu as l'appui total de la rubrique Oracle !

[jmguiche]

Je n'ai pas envie d'entrer dans une polémique, c'était une boutade.
Mais je constate simplement que, pour des fonctionnalités équivalentes, dans le monde de "développement sur mesure dans la gestion", un dévelopement POO est beaucoup plus couteux (plus de code, donc plus de bug, plus de jours hommes) et moins beaucoup moins performant que des approches classiques L4G.
Je n'émet pas de jugement dans d'autres contextes que "développement sur mesure dans la gestion", je ne parle que de ce que je connais.

Pendant quelques temps, j'ai du valider des propositions de maintenance sur un soft en C++ que je connaissait peu, ma technique était simple, je me disait "bon, en forms, ça devrait faire x, donc on va me proposer entre 5*x et 10*x". Je faisait faire des évals par deux équipes différentes et concurentes et c'est en effet ce que j'obtenais.
Je ne parlerai pas des projets .NET et JAVA !

J'ai aussi fait utiliser, dans un contexte bien particulier, la POO sous PL. Ca marche, c'est assez rapide, il y a des problèmes de contentions quand on parallélise des calculs de masse qui sont, d'après des plus spécialistes que moi, liés à la POO. Je n'ai pas encore tout résolu.

Je constate que ma propre experience rejoint totalement celle du Dr Dorsey
http://www.dulcian.com/Articles/Thic...ited_final.htm

Je constate aussi, que quand on parle de coût et de jours hommes, la réponse est toujours "encapsulation, héritage, polymorphisme, méthodes surchargées...". Je ne connais pas de référence, de texte, racontant une experience de type "je connais les deux mondes et, pour la gestion, la POO c'est mieux que l'approche classique ou L4G".

Mon métier, ce n'est pas de (faire) écrire du code, mais de résoudre des problèmes de gestion. C'est une approche que les entreprise devraient concevoir en terme de coût, de délais et de ROI, pas en terme technique de programmation.

Le fait que la POO soit la technologie majeure du marché n'est pas une preuve de son bien fondé. L'informatique n'a pas, dans le choix des technique, une approche "technologique" mais une approche bien différente.

Cela ne date pas d'hier ! Pourquoi pensez vous que, fin des années 80 les programmes d'éditions de factures ne se sont plus fait en cobol mais en C ?
Pour des problèmes de performances, de fiabilité, de maintenabilité, de productivité ? Parce qu'il est indispensable de communiquer avec les couches basses de l'OS et de la machine pour imprimer une facture ? Rien de tout ça évidemment. C'était... pour recruter. On manquait d'informaticiens et les jeunes diplomés ne voulaient pas faire du cobol.
C'est un exemple parmi tant d'autres.

[Vincent Rogier]

@jmquiche :

j'ai l'impression que tu te trompes de débat...

On n'est pas ici pour refaire le traditionnel débat procédural / objet.. Il y a d'autres forums pour ca...

Je ne suis pas un ardent défenseur de la POO ! Mon langage de prédilection est le C et au quotidien je défend le C contre les autres technos !

J'ai conçu la librairie OCILIB en C et non pas en C++ ou C# ou java... Il y a plein de raison pour ca et je pense que l'on serait d'accord dessus.

Pour en revenir au topic en question, nous avons la un membre qui s'intéresse à une techno Oracle existante depuis longtemps, bien conçue et relativement unique dans les gros SGBD et pour laquelle peu de ressources existent.

Je ne peux que l'encourager quelques soit mes affinités personnelles en termes de programmation...

J'ai jugé inopportun ta remarque qui ne pouvait que le décourager alors que sa démarche est très intéressante et positive.

[rvfranck]

Salut les gars,
Il y'a longtemps que j'ai envie de faire ce tuto, je le ferai d'autant plus que la rubrique Oracle approuve l'idée.

[jmguiche]

@jmquiche :

j'ai l'impression que tu te trompes de débat...

On n'est pas ici pour refaire le traditionnel débat procédural / objet.. Il y a d'autres forums pour ca...

Je ne suis pas un ardent défenseur de la POO ! Mon langage de prédilection est le C et au quotidien je défend le C contre les autres technos !

J'ai conçu la librairie OCILIB en C et non pas en C++ ou C# ou java... Il y a plein de raison pour ca et je pense que l'on serait d'accord dessus.

Pour en revenir au topic en question, nous avons la un membre qui s'intéresse à une techno Oracle existante depuis longtemps, bien conçue et relativement unique dans les gros SGBD et pour laquelle peu de ressources existent.

Je ne peux que l'encourager quelques soit mes affinités personnelles en termes de programmation...

J'ai jugé inopportun ta remarque qui ne pouvait que le décourager alors que sa démarche est très intéressante et positive.

Désolé si j'ai été décourageant, ce n'était pas mon but.
Cette techno existe. Le "savoir" ne fait de mal à personne, autant le partager.
Si tu ne voulait pas lancer le débat, il ne falait pas rebondit sur ma boutade !