Version imprimable
Bonjour,
Je suis désolé de vous déranger.
Je suis entrain de faire une petite étude sur les SGBDO.
J'ai besoin de quelques retours d'expérience.
En fait je dois répondre à la question suivante :
Pourquoi les SGBDO n'ont pas de succès comme les sgbdr ?
est ce à cause des performances insatisfaisantes,
est ce à cause de la complexité de mise en place ou impasse des professionnels ?
Merci pour vos réponses.
Cordialement,
je crois que c'est simplement dû au fait que les SGBDR habituelles intégrent déjà les objets. Les objets ne sont en plus pas vitaux puisque la modélisation Merise tend à "casser" les objets en tables statiques. Les analystes étant habitués à cela ne ressente pas le besoin d'un SGBDO. Enfin, c'est probablement trop nouveau encore et on manque de compétence.
Tout ceci ne sont qu'allégation, j'imagine ces raisons mais je ne suis pas sûr que ce soit la réalité ;)
Merci pour votre réponse Orafrance,
C'est un argument de plus, merci beaucoup.
Est ce que vous avez des retours d'expériences sur des entreprises qui ont utilisé les SGBDO ?
Merci encore.
Les SGBDO sont venus des milieux académiques et pas d'une demande utilisateur.
Les problèmes de performances n'ont jamais vraiment été résolus.
En fait, les éditeurs de SGBDR ont à peu près tout fait pour faire mourir le bébé dans l'oeuf :twisted:
Merci Fadace pour ces arguments,
J'ai vraiments du mal à trouver des gens qui en ont fait.
Qui pourront me donner leur avis.
Mais que penser des produits comme versant, JDO, ...
Merci encore.
:salut:
Pour ma part, j'ai utilisé 2 SGBDO. Le premier, durant mes études, s'appelait O2. L'un des premiers serveur purement Objet. Il était sympa dans l'idée, mais vraiment pas pratique! Il fallait développer toute son appli dans le serveur de base de données, ça plantait tout le temps, bref... il fallait vraiment revoir la copie. Il était par exemple impossible de porter du code déjà fait auparavent dans ce SGBDO...
Sinon j'ai aussi utilisé, et utilise toujours ObjectDB qui est une solution JDO. Superbe d'ailleurs! Une fois que l'ont a compris le fonctionnement de JDO ça marche sur toutes les implémentations, quelles soient purement objet ou relationnelles-objets. Mais, dans ce contexte, j'ai préféré utiliser ObjectDB car c'est un serveur qui utilise à fond la structure de Java. Lorsque l'ont utilise le client, il est possible de faire des requêtes utilisant les méthodes des objets stockés, ce qui m'aurait été impossible en utilisant un SGBD tel que MySQL. Par contre, je doute que ObjectDB supporte bien la montée en charge.
Néanmoins pour que l'objet entre dans les entreprises, il faudra déjà que les informaticiens s'y mettent. A mon boulot, sur 15 informaticiens, je suis le seul à connaitre un langage orienté objet. Si cette situation est possible en 2005, je ne crois pas qu'il soit concevable que les entreprises passent le pas. Surtout que pour les sociétés intéressées, il existe de bonnes solutions de mapping Objet-Relationnel.
Merci Adjanakis pour ces éclaircissements.
Donc, si je comprend bien l'avenir est dans les SGBDO-R et dans le mapping objet vers relationnel.
Merci encore à vous tous.
J'ai fait de la BD objet en licence info, donc y a un peu plus de 2 ans.
Ca ne ce fait pas dans toutes les facs je pense.
Ils me semble qu'on avait fait ça sur Oracle, donc si Oracle supporte l'objet ...
Par contre cette année en cours, un intervenant de chez Renault disais que pour eux ce qui les interessais c'etait les performances et que l'objet n'a pas vraiment fait ces preuves a ce niveau, mais bon je doute qu'ils aient vraiment essayé ou même qu'ils en soient capable. Et de toutes façon c'est tellement enorme leur datawarehouse qu'ils peuvent pas vraiment s'amuser a experimenter avec des technologies nouvelles.
Bref il y a deux sons de cloches.
Mais je trouve que en objet c'est quand même beaucoup plus naturel, au niveau de la modelisation.
Les tables utilitaires et uniquement relationnelles disparaissent vite.
La notion de pointeur peu aussi paraitre bizarre. :D
Il y a un autre argument de poids contre le SGBDOO. J'avais rencontré les équipes commerciales et de dev de O² .
En fait l'absence de client est essentiellement dû au poids du passé : comment jusitifier le passage d'une BD relationnelle vers un BDOO pour des quantité de données pharamineuses alors que les programmes qui utilisent ces énormes masses de données sont encore en Cobol ?
Les BDOO sont arrivée trop tôt et n'assurait pas la continuité des bases de données relationelles.
Ce handicap est maintenant franchi du fait de l'évolution des bases de données R vers l'objet, c'est à dire la base de données, objet relationnel.
Ceci a été introduit avec la nouvelle norme SQL:1999.
A lire dans mon prochain bouquin à paraître chez PearsonEduc (en collaboration avec Christian Soutou)
A +
Moi aussi je dois comparer SGBDR et SGBDO.
En fait jusqu'a il ya peu de temps je ne connaissais que les BD
Relationnelles.
Je suis juste au debut de mon etude mais ce que j'en vois:
- construire une SGBDR a partir d'un modele UML peut s'averer laborieux
malgre l'existance d'outils dedies. On est encore loin de la generation
automatique de code qui fait tout tout seul comme on veut et sans probleme.
- construire un SGBDO a partir d'un modele UML c'est du gateau
- j'avoue que je suis un peu manchot avec le SGBDO ou n'existe plus la
notion de cle .; enfin certains concepts propres aux SGBDR et bien
pratiques ne s'y retrouve pas .. a ce jour ca me gene un peu
- cote performance, j'attends de voir mais on m'a dit que les BD Objets sont particulierement performantes
- les BD objets je n'en connais pas beaucoup: le seule que je connais
est representee par quelques dizaines de personnes dans le monde.
Ca me generait de lancer un projet avce un outil aussi peu represente!
Voila .. je te transmettrais mes retours (d'ici 1-2 mois)
Je suis preneuse d'informations si tu en as (perfs? etc.)
Salut à tous,
Je veux relancer le débat. :D
Depuis 2005 jusqu'en 2013, il doit y avoir des changements. Est ce que quelqu'un peut m'aider en me fournissant des arguments solides et à jour motivant l'usage d'un SGBDR par rapport à un SGBDO ou vice à versa ?
Commence par chercher les SGBDO commercialisés aujourd'hui, ce sera un bon moyen d'évaluer si c'est une technologie qui a de l'avenir.
Merci de votre réponse.Citation:
Envoyé par al1_24
Mais pour vous, dans quel cas serait-il plus juducieux un SGBDO par rapport à un SGBDR ou l'inverse ?
Pour info, je suis entrain de développer une application basée sur la technologie Java EE, avec Tomcat comme serveur d'application et je veux choisir entre un SGBDR ou un SGBDO tout en motivant mon choix.
Par darwinisme, les SGBDOO n'existent pratiquement plus....
Le marché est réduit à peau de chagrin, et pour essayer de vendre des licences, les quelques éditeurs qui ont cela a leur catalogue en propose une version "libre" dont l'avenir est plus qu'incertain.
La raison de cette disparition : il est impossible d'indexer n'importe quel type d'objet. Or ce qui fait la force des SGBDR c'est avant tout l'indexation et les contraintes.
Sans index le système reste lent.
On sait cependant indexer certaines formes d'objet, pour certaines requêtes. Quelques exemples :
- le spatial, pour des recherches de proximités entre objets
- le XML pour certains prédicats des requêtes XQuery XPath.
mais aujourd'hui, les bons SGBD relationnels intègrent tout cela de manière native... Exemple MS SQL Server.
Mis à part des applications très particulières, il n'y a donc aucun intérêt d'utiliser un SGBD OO
A +
OK merci de m'avoir répondu.:ccool:
Cependant, lorsqu'on développe une application à partir d'un langage de programmation OO, ne serait-il pas mieux d'utiliser un SGBDO comme db4o plutôt qu'utiliser un SGBDR afin de ne pas être obligé d'adapter les deux mondes (monde orienté objet et monde relationnel) ?
La POO existe maintenant depuis pas mal d'années (2 décennies au moins je pense) et est très utilisée.
Si c'était vraiment mieux d'utiliser un SGBDOO avec la POO, les SGBDOO, Les SGBDR classiques seraient des dinosaures en voie de disparition et seraient remplacés par des SGBDOO. Visiblement, ce n'est pas le cas.
CQFD !
Il y a plusieurs manières de faire communiquer les objets d'un POO et les tables d'une BDDR :
1) via les Objets Réellement Merdiques qui semblent a priori pratiques mais nécessitent un temps d'apprentissage inutile de leur pseudo SQL, génèrent eux mêmes des requêtes souvent plus compliquées que celles qu'un programmeur SQL normal aurait écrites et de ce fait sont moins performants que du SQL natif ;
2) via un modèle objet constitué de vues SQL qui sont les seules interrogées par l'application mais qui sont, selon le SGBD utilisé, pas toujours pratiques pour la mise à jour des données ;
3) via la programmation en bases de données épaisses, c'est à dire en utilisant massivement les procédures SQL, le programme appelant une procédure SQL qui se charge de faire le boulot de mise à jour des données.
La meilleure solution est la combinaison des 2 dernières méthodes :
- mapping objet sur les vues SQL ;
- ajout, mise à jour, suppression de données en appelant des procédures SQL.
A noter, Oracle peut travailler avec des objets.
Mais ça soulève très vite tout un ta de problème: genre pour faire un order by, ou un distinct il faut créer une fonction de comparaison. A priori simple, mais entre deux objets "HOMME" comment on les classe? Par date de naissance, taille, poids? Et une fois ça décidé, faire une fonction qui compare les objets deux à deux, c'est avoir un temps de tri énorme, là ou un simple hash permettrait d'aller immensément plus vite.
Mais bon pareil, la doc pour l'orienté objet dans la BdD est pas très classe.
C'est clair. Merci pour la démonstration.Citation:
Envoyé par CinePhil
Cependant, vous avez énuméré 3 méthodes pour faire communiquer les objets d'un POO avec une BDDR. Personnellement, je n'en connais que deux :
1) On utilise un framework de persistance comme Hibernate en Java qui permet de faire la translation entre le monde orienté objet et le monde relationnel. Ce framework utilise comme langage d'interrogation des classes persistantes, le HQL (Hibernate Query Langage) dont la syntaxe est proche du SQL.
2) On utilise directement des requêtes SQL dans le POO et on se charge de faire des adaptations entre types (type SQL et type du langage POO).
Par souci de compréhension, merci de me fournir un exemple pratique pour comprendre les 3 méthodes que vous avez énuméré précédemment.
D'autre part, qu'appelez vous "vue SQL" et "procédure SQL" ?Citation:
Envoyé par CinePhil
Ne seraient-ils pas des requêtes SQL ?8O
Désolé, si mon niveau est si faible !
Ça, c'est la première méthode que je décrivais... avec tous les défauts engendrés par les ORM !Citation:
Envoyé par lamine87
- langage "proche" du SQL mais en réalité plus complexe et carrément galère quand il s'agit de faire des requêtes un peu complexes ;
- construction des requêtes par l'ORM pas du tout optimisée.
Ça c'est une 4ème méthode que je n'avais pas mentionnée car c'est en quelque sorte la moins professionnelle : on attaque directement les tables en écrivant les requêtes SQL et en les envoyant au SGBD. Ça fonctionne mais s'il y a modification de la structure des données, il faut aussi revoir les programmes qui utilisent la BDD.Citation:
2) On utilise directement des requêtes SQL dans le POO et on se charge de faire des adaptations entre types (type SQL et type du langage POO).
Citation:
Par souci de compréhension, merci de me fournir un exemple pratique pour comprendre les 3 méthodes que vous avez énuméré précédemment.
Un ORM fait classiquement un mapping objet sur les tables de la BDD. Il est même capable de construire tout seul les opérations CRUD sur les tables.Citation:
Envoyé par CinéPhil
Mais ce mapping ne correspond généralement pas à la construction des objets métier car dans une BDDR, les données sont réparties dans plusieurs tables pour optimiser leur accès.
Exemple...
On peut définir une classe "personne" avec les propriétés suivantes : nom, prenom, adresse, date_naissance, tel_fixe, tel_portable, courriel.
Par contre, une adresse est composée au moins de la partie rue, d'un code postal et d'une ville, laquelle est située dans un pays. C'est donc une propriété multivaluée et plusieurs adresses seront dans la même ville qu'il est inutile de répéter dans la base de données. Il y aura donc une table des villes et une clé étrangère référençant la ville dans la table des personnes si on considère qu'une personne n'a qu'une adresse, ou dans la table des adresses si on considère qu'elle peut en avoir plusieurs ou qu'on ne connaît pas forcément l'adresse de toutes les personnes enregistrées dans la BDD.
On voir aussi qu'une personne peut avoir plusieurs numéros de téléphone.
La solution consiste à modéliser de manière rigoureuse les données en séparant villes, pays, téléphones et personnes puis de réaliser une vue, c'est à dire une requête enregistrée, qui reconstitue la structure souhaitée pour l'objet métier personne.
Ce principe peut être généralisé pour réaliser ce que j'ai appeler un modèle objet qui est propre à l'application utilisatrice et correspond à la logique métier. On peut aussi l'appeler le "modèle organisationnel de données" en méthode Merise, de la même manière qu'il existe un "Modèle organisationnel des traitements".
Ensuite, le programme n'interroge que les vues qui sont à sa disposition. Si la structure des données change, il suffit de modifier la vue qui conservera, elle, la même structure (les mêmes colonnes de résultat) et il n'y a pas besoin de modifier les programmes.
Les vues s'interrogent en effet comme des tables :
Code:
2
Par contre, selon le SGBD utilisé, il peut être impossible de mettre à jour les données à travers une vue ; on ne peut pas toujours faire UPDATE la_vue ou bien DELETE FROM la_vue, ni même de INSERT INTO la_vue.
Il convient alors d'utiliser une procédure SQL, c'est à dire un programme qui va réaliser toutes les requêtes nécessaires, pour ces opérations d'insertion, de mise à jour ou de suppression.
De la même manière qu'en POO, on appelle une fonction publique d'une classe sans se préoccuper de toute la salade faite par cette fonction, en base de données épaisse, on appelle une procédure SQL sans savoir concrètement ce qu'elle fait dans la BDD mais en étant sûr de la solidité du résultat.
Un article de SQLPro sur le développement en bases de données épaisses est disponible ici.
Un seul mot à CinePhil : Merci !