bonjour
je voudrais savoir si les modèles relationnelles s'intègre facielemtn dans un bd objet?
j'ai un modèle realtionnelle tt fait et je voudrais savoir si c possible de le reutiliser dans une bd objet
merci

une BD objet ou une BD relationnel-objet ?

BD relationnel-objet
 
j'ai eu l'occasion de voir ce que ca donnait avec oracle, ben c'est pas beau !

base de donnée objet

je pense que ca va surtout dépendre de la complexité de ton modèle relationnel... C'est quoi ton SGBD ?

pour l'instant c'oracle mais la base de données est simple ques requets simples pas de trigger ou fonction ou procedure

Oracle, c'est du relationnel-objet...

.. en option, je veux dire

et tu veux une BD objet pour le fun ?

oracle gère le relationnel objet, mais j'ai encore jamais entendu parlé d'une boite qui s'en servait ... c'est vraiment la merde à utiliser !!!

moi le sujet m'intéresse. Je ne me sus pas encore penché dessus, mais je pense que les SGBDOO ont un bel avenir devant eux à moyen terme

Y au un SGBD OO écrit en Java et open source. Mais je ne me souviens plus du nom. Faut faire une recherche sur  
 
http://sf.net
 
A+

http://dmoz.org/Computers/Programm [...] -Oriented/

ne base de données oriente objet il y a zope et cache à ma connaissance

Ozone aussi

Sérieux, mais Zope, c'est pas une BDOO ?!
Tu commences à me faire douter... Zope, c'est framework Python non ?

ah bne je ne suios pas certaint mais il me semble que c'est unbddoo à confirmer

Zope :
 
"Users :
individuals who use of Zope's "out of the box" features to build websites. This audience is interested in making use of Zope's existing array of features to create content management solutions. They will likely make heavy use of "through the web" scripting using DTML, Page Templates, and Python Scripts as well as (of course) HTML and XML. They are generally less concerned about code reuse than the speed at which they can create a dynamic application or website.  
...
Persistent Components :
Zope provides a built-in, transparent Python object database called ZODB. This chapter describes how to create persistent components, and how they work in conjunction with the ZODB."
 
Ca répondra aussi à ton post sur Zope... mais ça vex pas dire que Zope est une BDOO

 
Ca fait tellement longtemps que les SGBDOO ont l'avenir devant eux que l'on se demande si ils n'oublieraient pas d'avancer.
 
Il y avait O2 aussi comme SGDBOO, mais si ma mémoire est bonne, c'est mort.

disons que c'est enseigné dans une moduel de base de données orientes objets donc je pense que c'est une BDOO mais bon je peux me tromper
l'erreur est humaine

OUI o2 a ete racheter par informix qui l'a envoyer aux oubliettes

de toute façon, les BDOO, ça n'a plus d'avenir... voilà venue l'ère des BD natives XML    !!! (qui d'ailleurs ne remplacent pas les SGBDR, mais les complètent)
Mais, sinon, l'OQL, j'trouve ça bien marrant...

ouais je sais bien, mais là je sens que ca va partir.
 
Quand tu penses par example aux plateforme J2EE dont le pricipal problème est la persistance des données... ( Entity Bean )

comment cela partir?
je connnait pas la plateforme qeu tu me dis c koi?

explique moi l'OQL je connait pas

l'OQL, c'est le SQL3 (je crois), c'est du SQL pour les BDOO !!!
Tu fais de la BDOO sans connaitre OQL ?

si je me trompe pas, SQL3 devrait réunir le SQL (requête pour sgbd relationnels) et OQL (requête pour SGBDOO)

Il y a ObjectStore aussi -> http://www.exln.com/products/objec [...] view.shtml La boite dans laquel je faisais mon stage utilisait cela et ils en étaient content. Apparement tu peux l'utiliser pour l'"interfacer" avec une BDD relationelle ou en tant que vrai BDD OO (-> j y connais rien).

 
Ca fait du bien de voir que certains se rappellent d'O2.
 
J'ai fait partie 3 ans de l'equipe d'O2 (interface Java), et c'est O2 qui a mis au point OQL qui a ensuite ete repris par les autres SGBDO.
 
Je peux repondre si vous voulez plus de details.
 
Renaud

bne dis moi j'ai un modele relationelle tt fait est ce poxxible de l'incorporer dans une bDOO?

toi tu devrais commencer par le commencement, c'est à dire "restes en au relationnel"... vu ce que tu dis, t'as pas l'air de trop maitrise en info...(Zope, J2EE, OQL...)
arrêtes de vouloir sauter les étapes : quand tu sauras faire du SQL et que les BDOO s'imposeront d'elles mêmes à toi, fais en, mais pas avant !

oui mais moi et autre chose que ce que veut l'entrerpise aussi si on peut developper cela en bDOO si c plus performant et plus rapide il faut que je passe en BDOO et si je n'y arrive pas j'apprendrais pas de pb

 
C'est pas vraiment comme ca qu'il faut aborder le probleme.
En effet, tu vas etre tente' de faire une table --> une classe.
Ca fonctionnera, c'est sur, mais ce sera pas optimum.
 
un SGBDR est base' sur les jointures (il est optimise pour).
un SBDDO est base' sur le parcours (il n'est pas aussi rapide en ~jointure).
 

Les SGBDO ont connu leurs heures de gloire il y a quelques années mais la plupart sont morts.
De connu, il y a versant je crois.
Mais c'est une approche assez différente. Il n'y a pas de jointure par exemple.

Disons que, pour faire un parallèle, OS/2 en son temps avait lui aussi de l'avenir...
Pour survivre, les éditeurs de SGBD objet auraient peut-être dû utiliser le modèle GNU (comme RedHat, par exemple). Mais c'est facile de dire cela après coup...    
 
chocoboy> SQL3 et OQL n'ont pas grand chose à voir. OQL existe et est normalisé depuis des années, seulement l'organisme qui l'a créé n'a jamais pu faire partir de l'OMG (Object Management Group), où les grosses boites (Microsoft, IBM, Oracle, ...) ont voulu faire leur propre standard : SQL3.
 
Je peux donner une différence pour une requête très simple, et vous aurez un aperçu des différences. SQL3 repose sur le standard historique SQL. Pour avoir le max d'une colonne, on écrit :

Les créateurs d'OQL ont pris quelques libertés avec le standard SQL historique, pour rendre ce langage entièrement fonctionnel. Ainsi, max() est une fonction qui attend une collection de numériques et renvoie un numérique. Ainsi la requête ci-dessus s'écrit en OQL :

ou bien, sous la forme suivante, qui fait un peu plus objet :

 
Verdoux> Le principe de la jointure existe malgré tout en OQL. Exemple :  

 
Mais il est clair que, contrairement au modèle relationnel, le modèle objet est, dans l'esprit, plus orienté parcours en profondeur (via les liens inter-objets) que parcours en largeur. Mais c'est précisément le langage de requêtes qui est censé compenser cette "orientation".
 
chocoboy> Pour info, les premiers SGBD XML natifs étaient en réalité... des applications reposant sur des SGBD objet !   (exemple : Excelon, d'ObjectDesign). Etonnant, non ?
Enn fait, pas du tout : la nature hiérarchique de XML rend les SGBD objet particulièrement adaptés à ce type d'applications. Parce que comme je le disais juste au dessus, le modèle objet est intrinsèquement hiérarchique, contrairement au modèle relationnel qui est intrinsèquement plat.
Et signe qui ne trompe pas : la plupart des éditeurs de SGBD objet ont essayé de se reconvertir dans le secteur des SGBD XML natif il y a environ 3-4 ans. Curieusement sans succès...

benou a écrit a écrit :   ouais je sais bien, mais là je sens que ca va partir.   Quand tu penses par example aux plateforme J2EE dont le pricipal problème est la persistance des données... ( Entity Bean )

J'avais lu un article il y a quelques mois qui faisait une étude de performance sur la persistence des EntityBean... Globalement, la conclusion de l'article était qu'aucun des serveurs d'application du marché n'avait d'offre satisfaisante. Ils avaient aussi essayé, pour le fun, d'utiliser un SGBD objet à la place du conteneur standard des serveurs d'application (en l'occurrence, le SGBD Versant). En plus, les auteurs soulignaient dans l'article qu'ils avaient transposé leur modèle relationnel directement dans le SGBD objet sans vouloir vraiement "faire objet", ce qui, toujours selon les auteurs, pénalisait un peu le SGBD objet (pas optimum, comme disait très justement Renaud). Résultat : sans optimisation particulière de la BD... 8 à 10 fois plus rapide. Une paille...
 
Cependant, vous remarquerez qu'aucun éditeur de serveur d'application ne s'est essayé à signer un accord avec quelqu'éditeur de SGBD objet que ce soit. Pourtant, depuis le temps que des SGBD objet existent, ils auraient dû avoir le temps...