Ben, l'avantage, c'est qu'une BdD relationnelle n'est pas vraiment adapté au modèle objet...
- Soit tu raisonnes en SQL, et alors tu fais des requetes et tu génères un objet correspondant,
- soit tu raisonnes en objet, et là, c'est la galère pour faire le lien avec le SGBDR (enfin, je vois, en Java, si ton objet contient un collection de liens vers d'autres objets, on va dire par exemple une objet Classe qui contient une collection de Profs : le probléme, c'est que ce sont des pointeurs vers les Profs.. Or, tu peux avoir (c'est même sûr) une ou plusieurs autres classes qui ont le même prof... Lorsque tu voudras 'persister' (stocker dans la base), tu devras vérifier si chaque prof existe ou pas, pour ne pas avoir de doublon...)..
C'est pour ça qu'il y a hibernate, qui fait le lien entre ta conception objet (bien propre objet) et l'implémentation du modèle en relationnel
http://www.hibernate.org/
Hibernate offre le lazy-loading, qui permet de récupérer un objet, sans récupérer toute la base !! (sinon en récupérant un objet Classe, on récupère les profs, qui eux mêmes enseignent dans d'autre classes, qui elles mêmes ont d'autres profs.. etc.. tu tires tout d'un coup, en ne voulant qu'un seul élément)
Le mieux serait d'avoir un système de base de données qui soit lui aussi objet... et ben en voilà une...
Regarde la doc, elle est bien foutue ( http://www.eyedb.org/quicktour_odl.php )
Il y a un langage particulier (ODL), qui te permet de representer ta structure d'objet, les héritages, les compositions...
Bref, tu raisonnes objet, tu programmes objet, et tu stockes objet.
[^] # Re: utilité ?
Posté par sylvain cherrier . En réponse à la dépêche Première publication en licence libre du SGBDO EyeDB. Évalué à 8.
- Soit tu raisonnes en SQL, et alors tu fais des requetes et tu génères un objet correspondant,
- soit tu raisonnes en objet, et là, c'est la galère pour faire le lien avec le SGBDR (enfin, je vois, en Java, si ton objet contient un collection de liens vers d'autres objets, on va dire par exemple une objet Classe qui contient une collection de Profs : le probléme, c'est que ce sont des pointeurs vers les Profs.. Or, tu peux avoir (c'est même sûr) une ou plusieurs autres classes qui ont le même prof... Lorsque tu voudras 'persister' (stocker dans la base), tu devras vérifier si chaque prof existe ou pas, pour ne pas avoir de doublon...)..
C'est pour ça qu'il y a hibernate, qui fait le lien entre ta conception objet (bien propre objet) et l'implémentation du modèle en relationnel
http://www.hibernate.org/
Hibernate offre le lazy-loading, qui permet de récupérer un objet, sans récupérer toute la base !! (sinon en récupérant un objet Classe, on récupère les profs, qui eux mêmes enseignent dans d'autre classes, qui elles mêmes ont d'autres profs.. etc.. tu tires tout d'un coup, en ne voulant qu'un seul élément)
Le mieux serait d'avoir un système de base de données qui soit lui aussi objet... et ben en voilà une...
Regarde la doc, elle est bien foutue ( http://www.eyedb.org/quicktour_odl.php )
Il y a un langage particulier (ODL), qui te permet de representer ta structure d'objet, les héritages, les compositions...
Bref, tu raisonnes objet, tu programmes objet, et tu stockes objet.