Version imprimable
Bonjour , aillant discuter avec pas mal de personne qui utilise Oracle ( DBA , chef de projet , developpeur ) aucun ne semble utilisé les objet dans ORACLE. Qu'en est t'il pour vous ?
je suis chef de projet dans une SSII toulousaine et a la charge d'un gros projet .net . Mon cahier des charges exigent que mon application puisse utiliser une base de donnée SQL server ou Oracle .
Je vous remercie pour vos avis et remarques
Cordialement
En effet, j'aime pas l'objet non plus. Merise marche trop bien pour se mettre de l'objet dans les pâtes. Au pire le XMLType suffit à gérer les metadonnées.
Bien d'accord ! Pourquoi y mettre de l'objet quand on a du parmesan !Citation:
Envoyé par orafrance
il fallait lire pattes :mrgreen:
Peu de gens utilisent les objets Oracle (surtout les objets non système) car peu de framework savent gérer l'API Objet Oracle.
Bien que les objets soit utilisables via SQL (utilisation limitée), Oracle propose une API non SQL dédiée aux objets beaucoup plus puissante et performante
Cette API est disponible en C/C++...
C'est pourquoi, les objets, présents depuis Oracle 8i n'ont jamais vraiment "décollé"... (sauf dans les cas des base manipulant des données de géo localisation)
Car bien que performant, leur "full" manipulation est limitée à certains langages
Bonjour , merci pour vos réponses , elle me conforte dans mon choix de ne pas utilisé les type ( objet ) pour mon futur projet . Je vais m en tenir a des champs xml et a du mapping O/R .
merci
Bonjour,
Dans les années 2001-2002, lors d'une mise à niveau en PL/SQL avancé, j'avais utilisé l'objet sous Oracle 8i.
Même si la fonctionnalité est séduisante, elle est lourde à digérer et à mettre en oeuvre. En effet, le raisonnement (modélisation objet) diffère de la modélisation relationnelle. Le langage SQL se complexifie au niveau syntaxe pour prendre en compte cette modélisation.
Que dire des outils de modélisation qui suivent plutôt des méthodologies comme Merise, et qui ne sont donc pas forcément adapter à une modélisation objet.
Pour ma part, je préfère largement le relationnel au niveau SGBD, et réserve plutôt l'objet au niveau du client, ou bien des serveurs d'applications (notamment tout ce qui est J2EE).
Il ne faut pas oublier non plus qu'il existe sur le marché des tas de couches logicielles qui prennent en charge ce mapping objet / relationnel, et qui ont en général pour rôle de masquer la base de données aux développeurs objets.
Par contre, ayant fait des années de PL/SQL, j'avoue que l'objet sous Oracle m'a bien aidé dans ce cadre. Rien de tel qu'un objet pour s'implémanter qq services sympathiques. Dans ce cadre, l'objet est instancié en mémoire à partir de sa classe, et il peut être utilisé seul, ou bien au travers d'une collection (tableau PL/SQL).
A mon sens, les support Objet d'Oracle a plus d'intéret dans des applications C/C++ car l'API Oracle de manipulation des objets est procédurale et non relationnelle.
Bien que les objets soient manipulables en SQL, ils tirent toute leurs puissance via leur utilisation non SQL.
Bonjour,
De mon coté je fais partie d'une société qui utilise les objets Oracle.
Nous avons pris le parti de placer les règles métier dans la base de données.
Lorsqu'un enregistrement est candidat à devenir une ligne dans le SI il est validé par l'objet correspondant.
Ce même objet est utilisé par les imports (sqlldr + plsql), les calculs (plsql) et l'interface (VB6).
Pour le moment un package de service "plat" est utilisé par le code VB pour faire l'interface avec les objets. Mais nous pensons passer à .net et dans ce cadre nous espérons faire prendre compte les objet Oracle par l'interface.
Ce sera une correspondance objet C# / objet PlSql ou alors une interface entre les deux. L'exploitation de ces objets depuis .net en utilisant une connexion donnée par Oracle semble possible d'après Microsoft et Oracle.
Pour le moment nous avons un peu plus d'une centaine d'objets développés sur 2 ans. Un peu tôt pour voir le bénéfice qu'on en tirera.
Deux soucis nous sont tombés dessus d'emblée :
1 Les soucis d'interblocage lors de la compilation / la création d'objets en masse
par un même script (à chaque objet un fichier, le script les lance par ordre alpha).
On a recensé les objets posant problème et on les crée deux fois.
Une fois dans le script et une seconde fois en fin de script.
2 L'import Oracle comme le datapump prend sur lui de créer un type objet avec un
identifiant UNIQUE.
=> Pas possible d'importer un schéma avec ses objets dans deux schémas dans la même
instance. On bricole en créant les types par script avant l'import.
A part ça pas de comportement étrange pour le moment. Ca marche.
Ce choix de l'objet nous oriente vers UML pour l'expression de la modélisation.
On est balbutiant de ce coté là mais ça s'annonce assez intéressant.
Pozzo
Nous utilisons les possibilité objet de PL pour des calculs assez nombreux dans des nomenclature, des algorithmes avec des parties communes et des variations plus ou moins complexes.
C'est certainement moins performant qu'une approche ensembliste sql quand on peut (mais cela permet de poser moins de verrous par transaction). Je ne suis pas sur que cela soit mieux (en terme de qualité technique et de maintenabilité ) que du PL tout simple, mais au moins, les parties communes à tout les calculs sont écrits une seule fois.
Par contre c'est fait en respectant la structure et la sémantique de la base de données : ce n'est pas la technique de programmation qui doit guider la structure de la base, c'est la sémantique.
Bref, si il n'y avait pas d'objet dans PL, j'aurais fait autrement et je ne m'en serais pas plus mal porté.
Relationnel vers objet c’est un sujet toujours chaud mais à ta place je me pencherais plutôt sur les problèmes liés à une application multi-base des données (Sql Serveur et Oracle) le saint Graal des programmeurs java.Citation:
Envoyé par bdurtaut
Sinon Relationnel c’est un model, POO c’est une technique de programmation. Tant que on n’oublie pas ça il n’y pas de conflit.
Voilà bien un fondamental que je n'arrive pas à faire comprendre.Citation:
Envoyé par mnitu