C'est génial l'objet mais d'aprés mes vieux souvenirs avec O2 :
- Ça ne résoud pas toujours tous les problèmes quand même.
- Ce n'est pas toujours aussi performant que le relationnel (surtout d'un point de vue ensembliste)
- Le relationnel, ça suffit dans la majeure partie des cas.
Et surtout, si j'ai bien compris, (corrigez moi si je me trompe), c'est trés dépendant d'un langage précis en général (à cause du mapping). Et ça je pense que c'est ce qui rebute les entreprises à passer aux bases de données objets. Avec Ozone par exemple, on ne peut l'utiliser qu'avec du Java. Bon ok. Mais une entreprise n'a pas forcément QUE des applis en java. Quid du site en PHP ? de l'appli en VB du service truc ? ou en python du service machin ? Quand bien même elle accepte de tout passer en Java , il y a forcément une période de transition (plus ou moins longue, selon le nombre d'appli à réécrire), qui ne doit pas être du tout évidente à mettre en place.
Faut il une réplication des données entre le vieux SGBDR et le nouveau SGBDOO ? Y a t-il ce qu'il faut pour faire un "pont" entre les appels SGDBR vers le SGBDOO ? etc...
Le gros avantage des bases de données relationnelles, c'est que c'est accessible par la majeure partie des langages (objets et non objets). Et c'est pour cela que ça reste encore trés ancré dans les entreprises. Les coùt induits d'une migration vers un SGBDOO sont à mon avis beaucoup trop important pour qu'une entreprise face le pas. Ou alors cela sera adopté pour un type d'application précis. Et donc pour le reste, un SGBDR sera toujours nécéssaire.
Bref, à première vu, avec quelques essais, le SGBDOO est trés alléchant. Mais il semble y avoir tout un tas de problèmes derrière qui ne sont pas tout à fait négligeables.
Pendant longtemps, et sûrement encore aujourd'hui, les SGBDOOs ont été une techno réservées aux geeks. J'entend par là que sur le papier, c'est joli, c'est un sujet passionnant pour les chercheurs, ça fait des années qu'on nous loue les grands avantages des SGBDOOs, mais sans vraiment avoir résolu tout les gros problèmes.
Et donc pour les entreprises, j'imagine bien que cela n'apporte pas encore suffisement d'avancées spéctaculaires pour leur système d'information, rien qui ne vaille le cout de migrer.
Ce que je veux dire, est que, ok, pour le développeur, c'est jouissif, en 3 lignes il fait des choses merveilleuses, mais si elles prennent 3 fois plus de temps qu'avec un SGBDR (j'éxagère sûrement, mais l'idée est là), associé à un cout enorme de migration, où est l'avantage pour le système d'information de l'entreprise ? Où est son intérêt dans cette histoire ? (sans parler qu'actuellement, cela la rend prisonnière d'une techno comme Java par ex)
Les vraies réponses à ces dernières questions permettraient certainement de comprendre pourquoi les SGBDOOs sont encore des "niches" technologiques.
[^] # Re: Base de données ... relationnelles (soyons précis)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ma vie, mon oeuvre ;-). Évalué à 3.
- Ça ne résoud pas toujours tous les problèmes quand même.
- Ce n'est pas toujours aussi performant que le relationnel (surtout d'un point de vue ensembliste)
- Le relationnel, ça suffit dans la majeure partie des cas.
Et surtout, si j'ai bien compris, (corrigez moi si je me trompe), c'est trés dépendant d'un langage précis en général (à cause du mapping). Et ça je pense que c'est ce qui rebute les entreprises à passer aux bases de données objets. Avec Ozone par exemple, on ne peut l'utiliser qu'avec du Java. Bon ok. Mais une entreprise n'a pas forcément QUE des applis en java. Quid du site en PHP ? de l'appli en VB du service truc ? ou en python du service machin ? Quand bien même elle accepte de tout passer en Java , il y a forcément une période de transition (plus ou moins longue, selon le nombre d'appli à réécrire), qui ne doit pas être du tout évidente à mettre en place.
Faut il une réplication des données entre le vieux SGBDR et le nouveau SGBDOO ? Y a t-il ce qu'il faut pour faire un "pont" entre les appels SGDBR vers le SGBDOO ? etc...
Le gros avantage des bases de données relationnelles, c'est que c'est accessible par la majeure partie des langages (objets et non objets). Et c'est pour cela que ça reste encore trés ancré dans les entreprises. Les coùt induits d'une migration vers un SGBDOO sont à mon avis beaucoup trop important pour qu'une entreprise face le pas. Ou alors cela sera adopté pour un type d'application précis. Et donc pour le reste, un SGBDR sera toujours nécéssaire.
Bref, à première vu, avec quelques essais, le SGBDOO est trés alléchant. Mais il semble y avoir tout un tas de problèmes derrière qui ne sont pas tout à fait négligeables.
Pendant longtemps, et sûrement encore aujourd'hui, les SGBDOOs ont été une techno réservées aux geeks. J'entend par là que sur le papier, c'est joli, c'est un sujet passionnant pour les chercheurs, ça fait des années qu'on nous loue les grands avantages des SGBDOOs, mais sans vraiment avoir résolu tout les gros problèmes.
Et donc pour les entreprises, j'imagine bien que cela n'apporte pas encore suffisement d'avancées spéctaculaires pour leur système d'information, rien qui ne vaille le cout de migrer.
Ce que je veux dire, est que, ok, pour le développeur, c'est jouissif, en 3 lignes il fait des choses merveilleuses, mais si elles prennent 3 fois plus de temps qu'avec un SGBDR (j'éxagère sûrement, mais l'idée est là), associé à un cout enorme de migration, où est l'avantage pour le système d'information de l'entreprise ? Où est son intérêt dans cette histoire ? (sans parler qu'actuellement, cela la rend prisonnière d'une techno comme Java par ex)
Les vraies réponses à ces dernières questions permettraient certainement de comprendre pourquoi les SGBDOOs sont encore des "niches" technologiques.