Tu deterres une vieille hache de guerre entre les style de base de donnees.
Dans les annees 90 on(enfin certains) a cru que les BDD Objets allaient supplanter les SGBDR.
Finalement, si on programme tout en objet alors qu'le besoin de ces notions ringardes de tables/jointures et autres concepts desuets.
L'inconvenient c'est que beaucoup de problemes ne se pretent pas a cette approche. Quand tu veux manipuler des grosses masses de donnees, des cubes de donnees ou calculer des rapports statistiques enormes, ca n'est tout betement pas tres efficace de traiter individuellement chaque entree comme un objet, creer un instance, faire trois operations dessus et le detruire. Qui plus est les languages non objet n'ont pas disparu et restent bien vivaces.
En fait les gros consommateur de BDD ce sont des programmes de gestion dans les entreprises, les ERP en particulier. Et franchement, un backend Relationnel garantissant une bonne integrite leur est bien plus utile qu'une jolie BDD Objet.
A cela on peut ajouter que la plupart des gros projets utilisent plusieurs languages/environnements et que les stockages d'objets en bases sont souvent specifiques a un language.
Quand a changer de BDD comme de chemise, j'aimerai bien. Mais finalement le probleme c'est que 1) la plupart des BDD commerciales ont introduit des extensions proprio (gestion des arbres sous Oracle par exemple) 2) certaines BDD n'implementent que tres partiellement(ou exotiquement) le SQL (MySQL au hasard), 3) quand on veut tirer le maximum de ses requetes on peut etre amene a l'ecrire en vue du moteur sous-jacent et obtenir des resultats tres differents entre deux bases 4) certains besoins pourtant courants n'ont pas d'implementation standard (recherche FullText, donnees GIS ) 5) des qu'on utilise des "stored procedures" on a des chances de se lier profondement à une base spécifique.
Bref, y'a des systeme d'abstraction ODBC, JDBC, DBI ..... mais si on veut tirer les derniers bouts de performance ou profiter de fonctionnalites avancees on est souvent oblige de specialiser le code pour une base particuliere.
[^] # Re: Et mysql
Posté par Christophe Renard . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 6.
Dans les annees 90 on(enfin certains) a cru que les BDD Objets allaient supplanter les SGBDR.
Finalement, si on programme tout en objet alors qu'le besoin de ces notions ringardes de tables/jointures et autres concepts desuets.
L'inconvenient c'est que beaucoup de problemes ne se pretent pas a cette approche. Quand tu veux manipuler des grosses masses de donnees, des cubes de donnees ou calculer des rapports statistiques enormes, ca n'est tout betement pas tres efficace de traiter individuellement chaque entree comme un objet, creer un instance, faire trois operations dessus et le detruire. Qui plus est les languages non objet n'ont pas disparu et restent bien vivaces.
En fait les gros consommateur de BDD ce sont des programmes de gestion dans les entreprises, les ERP en particulier. Et franchement, un backend Relationnel garantissant une bonne integrite leur est bien plus utile qu'une jolie BDD Objet.
A cela on peut ajouter que la plupart des gros projets utilisent plusieurs languages/environnements et que les stockages d'objets en bases sont souvent specifiques a un language.
Quand a changer de BDD comme de chemise, j'aimerai bien. Mais finalement le probleme c'est que 1) la plupart des BDD commerciales ont introduit des extensions proprio (gestion des arbres sous Oracle par exemple) 2) certaines BDD n'implementent que tres partiellement(ou exotiquement) le SQL (MySQL au hasard), 3) quand on veut tirer le maximum de ses requetes on peut etre amene a l'ecrire en vue du moteur sous-jacent et obtenir des resultats tres differents entre deux bases 4) certains besoins pourtant courants n'ont pas d'implementation standard (recherche FullText, donnees GIS ) 5) des qu'on utilise des "stored procedures" on a des chances de se lier profondement à une base spécifique.
Bref, y'a des systeme d'abstraction ODBC, JDBC, DBI ..... mais si on veut tirer les derniers bouts de performance ou profiter de fonctionnalites avancees on est souvent oblige de specialiser le code pour une base particuliere.