Quels sont les avantages et les inconvénients des bases de données objet?

Question

Il existe de nombreuses informations sur les mappeurs d’objets relationnels et sur la meilleure façon d’éviter les incohérences d’impédance, qui semblent toutes discutables si l’on utilisait une base de données d’objets. Ma question est pourquoi est-ce que ceci n'est pas utilisé plus fréquemment? Est-ce pour des raisons de performances ou parce que les bases de données objet font que vos données deviennent la propriété de votre application ou est-ce dû à autre chose?

Answer 1

• Familiarité. Les administrateurs de bases de données connaissent des concepts relationnels. les objets, pas tellement.
• Performances. Il a été prouvé que les bases de données relationnelles évoluaient beaucoup mieux.
• Maturité. Le langage SQL est un langage puissant et développé depuis longtemps.
• Prise en charge des fournisseurs. Vous pouvez choisir entre de nombreux autres outils propriétaires (serveurs SQL) et tiers (interfaces administratives, mappages et autres types d'intégration) autres que ceux utilisés avec le SGBDO.

Naturellement, le modèle orienté objet est plus familier au développeur et, comme vous le dites, épargnerait un élément parmi ORM. Mais jusqu’à présent, le modèle relationnel s’est avéré être l’option la plus pratique.

Voir aussi la question récente, Bases de données relationnelles vs orientées .

Answer 2

Je me sers de db4o , qui est une BOOD et résout la plupart des inconvénients indiqués:

• Familiarité - Les programmeurs connaissent mieux leur langage que SQL (voir Requêtes natives)
• Performances - celle-ci est très subjective mais vous pouvez consulter PolePosition
• Assistance et maturité des fournisseurs - peuvent évoluer dans le temps
• Ne peut pas être utilisé par des programmes n'utilisant pas le même cadre. Il existe des normes OODB et vous pouvez utiliser différents frameworks
• Le versionnage est probablement un peu un problème - Le versionnage est en fait plus facile !

Les avantages qui m'intéressent sont:

• Requêtes natives - Db4o vous permet d'écrire des requêtes dans votre langage à saisie statique afin que vous n'ayez pas à vous soucier de la saisie incorrecte d'une chaîne et de la recherche de données manquantes au moment de l'exécution,
• Facilité d'utilisation - La définition de la logique commerciale dans la couche de domaine, la couche de persistance (mappage) et enfin la base de données SQL constitue certainement une violation de DRY. Avec OODB, vous définissez votre domaine auquel il appartient.

Je suis d’accord - les OODB ont un long chemin à parcourir mais ils y vont. Et il existe des problèmes de domaine qui sont mieux résolus par OODB,

Answer 3

Une objection aux bases de données objet est qu’elles créent un couplage étroit entre les données et votre code. Cela peut être correct pour certaines applications, mais pas pour d'autres. Une bonne chose que vous offre une base de données relationnelle est la possibilité d’afficher de nombreuses vues sur vos données.

Ted Neward explique cela et beaucoup plus à propos du SGBDO que de succès.

Answer 4

Cela n’a rien à voir avec les performances. Autrement dit, toutes les applications fonctionneraient mieux avec un OODB. Mais cela mettrait également beaucoup d'administrateurs de base de données au chômage / devant apprendre une nouvelle technologie. Même plus de personnes seraient au chômage à corriger des erreurs dans les données. Il est peu probable que les OODB soient populaires auprès des entreprises établies. Gavin semble ne rien savoir, un meilleur lien serait Kirk

Answer 5

Inconvénients:

• Ne peut pas être utilisé par les programmes qui n'utilisez pas aussi le même cadre pour accéder au magasin de données, en faisant plus difficile à utiliser à travers le entreprise.

• Moins de ressources disponibles en ligne pour     base de données non basée sur SQL

• Pas de compatibilité entre bases de données     types (impossible de changer de base de données     fournisseur sans changer tous les     code)

• Le versionnage est probablement un peu un     chienne. Je suppose que l'ajout d'un nouveau     la propriété d'un objet n'est pas tout à fait aussi     facile que d'ajouter une nouvelle colonne à un     table.

Answer 6

S & # 246; ren

Toutes les raisons que vous avez indiquées sont valables, mais je vois que le problème avec OODBMS est le modèle de données logique. Le modèle objet (ou plutôt le modèle de réseau des années 70) n'est pas aussi simple que le modèle relationnel, il est donc inférieur.

Answer 7

jodonnel, je ne vois pas comment l’utilisation des bases de données objet couple le code d’application aux données. Vous pouvez toujours extraire votre application de la bibliothèque OODB en utilisant un modèle de référentiel et la remplacer par une base de données SQL sauvegardée par ORM si vous concevez correctement les éléments.

Pour une application OO, une base de données OO fournira un ajustement plus naturel pour les objets persistants.

Ce qui est probablement vrai, c’est que vous associez vos données à votre modèle de domaine, mais c’est le point crucial!

Ne serait-il pas bon de disposer d'une seule façon d'examiner à la fois les données, les règles métier et les processus en utilisant une vue centrée sur le domaine?

Ainsi, un gros avantage est qu'un OODB correspond à la façon dont la plupart des applications logicielles orientées objet de niveau entreprise sont conçues. Il n'y a aucun effort supplémentaire pour concevoir une couche de données utilisant une conception (relationnelle) différente. Moins cher à construire et à entretenir et, dans de nombreux cas, de meilleures performances générales.

Inconvénients, juste un manque général de maturité et d’adoption, je pense ...