Pourquoi les bases de données orientées objet n'ont-elles pas (encore) réussi? [fermé]

Question

C'est la question. Ne donnez qu’une des raisons pour lesquelles vous pensez que la plate-forme OODB a échoué ou pourquoi de nombreux systèmes utilisent encore des bases de données relationnelles.

Answer 1

Pouvons-nous répondre plus d’une fois? Une autre raison est que les bases de données relationnelles ont une base solide en mathématiques: de la définition d'une relation aux formes normales, la théorie est très solide. Il est vrai que le modèle relationnel ne correspond pas bien à OO, mais à mon humble avis, les avantages et la stabilité de ce modèle l’emportent sur le problème de la cartographie.

Answer 2

La raison principale est SQL. Il est très utile de pouvoir utiliser les données d'une base de données dans d'autres contextes que l'application, et souvent avec des bases de données objet, les données sont stockées dans un format qui ne peut pas être facilement interrogé. Avec une base de données relationnelle, les données peuvent par exemple faire partie d’un entrepôt de données, ou simplement être interrogées par les administrateurs système, etc.

Answer 3

Je pense que c'est parce que " bases de données d'objets " résolvent un problème que (presque) personne n'a réellement. Pour une persistance simple des graphes d'objets, la sérialisation intégrée à la plupart des environnements OO est "assez bonne". Si vous souhaitez effectuer des opérations sophistiquées sur un sous-ensemble de vos données, une base de données relationnelle et SQL conviennent parfaitement.

Hormis certaines applications marginales (d'énormes graphes d'objets qui ne peuvent pas être conservés en mémoire, mais pour lesquels les relations ne se simplifient pas vraiment pour l'utilisation de SGBDR), ces outils ne sont vraiment pas nécessaires.

Answer 4

Ce n’est pas parce que les OODB ne sont pas le courant dominant que nous devons quand même considérer les succès qu’ils ont obtenus. Cache et Zope sont tous deux largement utilisés (relativement) mais seraient considérés comme des succès selon certaines normes.

Peut-être que la principale raison pour laquelle OODB n’a pas pris racine de manière spectaculaire est le succès des systèmes hybrides relation-objet qui exploitent la plupart des parts de marché potentielles de OODB: PostgreSQL et Informix.

Je sais que cela ne répond pas directement à la question, mais que cela fait, je pense, partie de l'équation. Dans l’ensemble, cependant, je pense que cet élan et les processus de pensée profondément enracinés qui sous-tendent les bases de données relationnelles rendent difficile le basculement des utilisateurs. Actuellement, la profession de DB est formée presque exclusivement à la théorie relationnelle, ce qui rend vos professionnels très intéressés à éviter la BDOD et le milieu universitaire enseigne la théorie à la DB pour les praticiens presque exclusivement sur le relationnel.

Jusqu'à ce que les grandes entreprises, les professeurs principaux, le curriculum et les collaborateurs autres que les développeurs soient prêts à gérer OODB, j'estime qu'il est peu probable que la masse suscite un intérêt, quelle que soit sa qualité du point de vue du développement.

Answer 5

Eh bien, c'est étrange, n'est-ce pas? Il existe une poussée en faveur de la conception pilotée par domaine comme le zénith de l'analyse et de la conception orientées objet, et il existe des modèles d'entreprise permettant de tirer parti des systèmes ORM pour conserver nos objets. Cela me semble tout à fait logique. Si votre conception DESIGN est orientée objet et est centrée sur le domaine, une PODA sera grandement bénéfique pour votre application.

Outre les problèmes liés à la maturité et à l’adoption, d’un point de vue philosophique, un OODB apparaîtrait bénéfique ou une application OO. ne pas avoir à maintenir cette couche de mappage pour commencer;)

Mais regardez, si vous ne créez pas de lecteur de domaine et n'utilisez pas d'objets en tant qu'objets de données et n'aimez pas vos processus stockés, vous ne l'obtiendrez pas vraiment;)

Answer 6

Les RDBM sont (construits sur une base théorique solide, présents sur le marché depuis bien plus longtemps, peuvent modéliser les données plus fidèlement que les MDEO dans de nombreux cas, peuvent être utilisés par plus d’administrateurs de base que les MDEO). C'est l'une des raisons sous la forme d'un tuple relationnel.

Answer 7

Si je peux amplifier le point de Phil: la normalisation de SQL. Les OODB ont essayé des langages de requête tels que OQL, mais ils ne semblaient jamais suivre un vrai standard. La qualité des langages de requête était également suspecte, probablement en raison d'un manque de standardisation. Les normes favorisent la concurrence, source de qualité.

Answer 8

Une des raisons est que les bases de données concernent les données et les objets les structures et les algorithmes. Une fois que vous avez pris les données et les avez intégrées dans des classes, vous caractérisez les relations et les opérations dans une structure statique. Les bases de données, quant à elles, consistent à déstructurer les données en un groupe d'instances de tables atomiques pouvant être réassemblées en différentes structures (généralement avec des classes) sans perturber l'intégrité des atomes.

Les bases de données ressemblent quelque peu aux hexahexaflexagones.

Answer 9

Cela et les autres mappeurs. Grâce à eux, la différence par rapport aux véritables DB OO devient bien moindre, tandis que les avantages susmentionnés restent valables.

Answer 10

Les personnes disposant de connaissances techniques ne prennent pas de décisions coûteuses en matière de technologie. Les entreprises qui utilisent des bases de données relationnelles emploient un grand nombre de personnes qui se sentent menacées par les OODB et éviteront par conséquent d'apprendre à leur sujet.

Answer 11

Je pense qu'il y a deux raisons philosophiques.

Premièrement, les gens ont tendance à séparer la persistance de la fonctionnalité réelle. Une fois que vous supprimez la "vie" d'un objet, loin de lui et le garder principalement pour la persistance, il devient un disque, et alors il y a une tendance à le traiter comme un "sans vie" objet de données.

Ensuite, lorsque les gens pensent à une vaste collection de choses très similaires, ils commencent à les considérer comme des tableaux plutôt que comme des objets.

Je pense qu'avec O / R, la distinction commence à disparaître. Par exemple, j'utilise hibernate pour vider des hiérarchies de classes vraiment complexes dans une base de données MySQL. Cependant, je n’écris pas de choses critiques pour la performance de mon projet, donc je suis sûr que ce n’est pas fait efficacement.

Answer 12

La raison de la lenteur de l'adoption des OODB repose en grande partie sur quelques facteurs clés qui rendent les bases de données SQL relationnelles plus populaires et / ou plus appropriées. Alors que les bases de données purement orientées objet sont maintenant dans un état où elles surmontent la plupart des inconvénients du modèle relationnel, il manque quelques éléments clés.

D'une part, ils ont tendance à manquer de prise en charge de la gestion de la base de données centrale, bien que cela soit rapidement corrigé dans divers produits.

Une deuxième raison est que très peu de systèmes implémentent un langage de requête standard et reposent plutôt sur un langage de programmation ou des langages de requête spécialisés pour extraire et manipuler les données stockées. C'est un obstacle pour beaucoup de gens s'ils doivent apprendre un nouveau langage d'interrogation en plus de l'état d'esprit totalement différent d'un programmeur habitué aux solutions basées sur NoSQL. De plus, la plupart des bases de données relationnelles / basées sur SQL prennent désormais en charge la conception orientée objet. De plus, nous avons des wrappers comme ORM que beaucoup utilisent pour "contourner". les problèmes de bases de données relationnelles ne sont pas facilement disponibles dans le langage de programmation choisi.

Mais ces problèmes existent principalement dans les environnements d’entreprise. En tant que bases de données intégrées dans de petits appareils, en tant que stockage de sites Web et dans des domaines tels que l'aérospatiale, ils sont devenus très populaires et ont souvent totalement remplacé le besoin de bases de données relationnelles régulières.

Qui sait ce que l'avenir nous réserve?

Answer 13

La sérialisation fournie par la plupart des langues vous permet d’aplatir les attributs d’objet et de les stocker facilement dans le SGBDR. De même, la récupération d’objets n’est pas un gros problème. Les bases larges et solides manquent encore, ce qui empêche l’application du SGBDO.

Je pense actuellement faire cela comme projet de thèse de maîtrise visant à fournir un cadre général pour le SGBDO qui supporte presque tous les composants couramment utilisés dans les SGBDR actuels, fournissant ainsi un SGBD structuré non linéaire. Pendant mes études, je suis tombé sur un projet appelé db4o, une approche (implémentée) consistant à utiliser OODBMS uniquement pour Java et .net, ce qui pourrait être une autre raison du manque de généralité pour tous les types de plates-formes et de langages.

Answer 14

Je pense que c’est parce que de grands acteurs comme Oracle investissaient dans des bases de données relationnelles alors que le mouvement orienté objet prenait de l’ampleur… peut-être qu’ils deviendraient la norme si Oracle / Microsoft y investissait énormément… ce qui semble peu probable. parce qu'ils n'ont pas de raison forte de le faire ... cela simplifiera la vie de nombreux programmeurs ... mais "rendre la vie des programmeurs plus simple" n’est pas un très bon objectif commercial pour eux!