sgbdo vs sgbdr

[zambi]

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,

[orafrance]

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é

[zambi]

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.

[fadace]

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

[zambi]

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.

[Adjanakis]

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.

[zambi]

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.

[mirak63]

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.

[SQLpro]

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 +

[quemener]

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.)