quels sont les inconvénients et les avantages d'utiliser une base de données d'objet ou une base de données relationnelle pour un développement Web régulier qui implique beaucoup de crud?
8 Réponses :
Ceci explique à peu près les avantages et les inconvénients:
Cet article est tremblement. Des commentaires comme, "OOTBMS peut dans certains cas être plus rapide que le SGBD relationnel car les données ne sont pas stockées dans des lignes et des colonnes relationnelles, mais comme des objets", trahir une ignorance complète de ce que le modèle relationnel est à peu près. Il serait logique si "relationnel" a été remplacé par "SQL". En outre, la fermeture argument n'a aucune place dans une encyclopédie.
@Marcelo: " peut dans certains cas être plus rapide et (mon ajout) peut dans de nombreux cas être plus lent". Il peut pleuvoir au Nevada demain ou ce n'est peut-être pas :)
@YPERCUBE: Ce n'était pas le "peut être plus rapide" qui me dérangeait. C'était "des lignes et des colonnes relationnelles" qui me sont arrivées. Toute personne ayant plus qu'une connaissance réussie du modèle relationnel sait qu'il n'a absolument rien à voir avec des rangées et des colonnes, et que les rangées et les colonnes de tables SQL sont une mauvaise mimétie des relations, des tuples et des attributs de la théorie.
Le concept d'une OODBM est assez brisé et les différentes offres commerciales et libres qui ont émergé au cours des dernières décennies ont à peine fait une tirette sur le marché.
Le modèle relationnel est plus puissant que les modèles d'objets en termes de types de questions que vous pouvez poser de vos données. Malheureusement, SQL a jeté une grande partie du pouvoir expressif que le modèle relationnel est capable, mais même sous cette forme diluée, il est toujours plus facile d'exprimer des requêtes dans SQL que dans une base de données OO typique (que ce soit ORM ou OOWBMS).
Les requêtes dans une OOTBM sont principalement conduites par les opérateurs de navigation, ce qui signifie que si votre base de données de vente a des vendeurs possédant leurs ventes, alors interrogeant les ventes mensuelles pour un SKU donné est non seulement susceptible d'être ralentiellement, mais très gênant exprimer. Considérez également un modèle de sécurité qui accorde aux employés l'accès aux bâtiments. Quelle est la bonne façon d'exprimer cela? Les employés devraient-ils tenir une collection de bâtiments qu'ils peuvent accéder ou les bâtiments devraient-ils détenir une collection d'employés qui leur ont accès? Plus précisément, pourquoi l'une des catégories devrait-elle avoir à avoir une collection de l'autre cuite à sa conception? Et, selon votre choix, comment demanderiez-vous quelles paires d'employés ont plus d'un bâtiment qu'ils peuvent accéder en commun? Il n'y a pas de modèle de navigation simple qui peut répondre à une telle question. La solution sensible - un objet "accès" - est essentiellement une réversion à un schéma relationnel correctement normalisé et nécessite une sorte de langage de requête qui emprunte fortement de l'algèbre relationnelle afin de répondre à la question sans massif sur-la- Transfert de données de fil.
considère également une autre force majeure pour l'OOTBMS: méthodes, en particulier héritage avec des méthodes virtuelles. Une clinique sportive pourrait avoir différentes métriques de risque de blessure pour différents types d'athlète. Dans le monde ORM, cela serait automatiquement exprimé comme une hiérarchie de classe, avec Le modèle relationnel permet au SGBM d'exprimer des connaissances de manière extrêmement distillée basée sur la logique de prédicat, ce qui permet de joindre les différentes dimensions des faits que vous le stockez, projetés, filtrées, groupées, résumées et autrement réorganisées dans un complètement ad hoc. Il vous permet d'utiliser facilement les données d'une manière qui n'étaient pas anticipées lorsque le système a été conçu à l'origine. Le modèle relationnel permet ainsi l'expression la plus pure des connaissances que nous connaissons. En bref, le modèle relationnel tient des faits purs - rien de plus, rien de moins (et certainement pas des objets, ni de ses proxies).
Sur une note historique, le modèle relationnel a émergé en réponse à un état de fait désastreux avec le réseau existant et les SGBR hiérarchiques de l'époque, et largement (et à juste titre) les a déplacés pour tous sauf une petite niche de domaines d'application (et Même ceux-ci sont probablement restés en grande partie parce que SQL n'a pas réussi à livrer sur la puissance RMS). Il est profondément ironique qu'une grande partie de l'industrie désigne essentiellement essentiellement pour les "bons vieux jours" des bases de données théoriques du réseau, qui est essentiellement à quoi les OOTBMS et la récolte actuelle des bases de données NOSQL reviennent. Ces efforts critiquent à juste titre SQL pour son non-respect des besoins actuels, mais malheureusement, ils ont supposé (à tort et probablement de l'ignorance pure) que SQL est une expression de haute fidélité du modèle relationnel. Par conséquent, ils ont négligé d'envisager même le modèle relationnel lui-même, qui n'a pratiquement aucune des limitations qui a entraîné autant de SQL, souvent vers OOTBMS. athlète à la racine et une méthode virtuelle, int blessureRiskscore () mis en œuvre par chaque classe dérivée. Le problème est que cette méthode est invariablement mise en œuvre sur le client, non à la fin de l'arrière, donc si vous souhaitez trouver les 10 athlètes de risque les plus élevés à tous les sports de votre clinique, le seul moyen de le faire est de chercher tous les athlètes à travers le filez-les et passez-les à travers une file d'attente prioritaire côté client. Je ne connais pas également le monde d'Oodbms, mais je pense que le même problème se produit, car les moteurs de stockage ne stockent généralement que suffisamment de données pour réhydrater des objets dans le langage de programmation du client. Dans le modèle relationnel ou SQL, vous exprimeriez la notation des risques de blessure comme une vue, ce qui pourrait être simplement l'union des vues de type athlète. Ensuite, vous venez de poser la question. Ou vous pouvez demander des questions plus complexes telles que "qui ont eu la plus grande augmentation de leur risque de blessure depuis le dernier mois?" Ou même, "quel score de risque s'est avéré être le meilleur prédicteur de la blessure au cours de la dernière année?". Plus important encore, ces questions peuvent toutes être répondues à l'intérieur de la SGBD sans rien de plus que la question et la réponse parcourant le fil.
Il est clair que vous n'avez jamais utilisé de pierres précieuses. Aucun de vos arguments n'a aucun sens
1 Le modèle d'interrogation de Gemstone est beaucoup plus puissant que celui des bases de données relationnelles
2 Votre exemple de requête est beaucoup plus lent et difficile à exprimer dans une base de données relationnelle que chez Gemstone, en particulier lorsque vous essayez de faire une analyse multidimensionnelle (Data-région).
3 Le modèle relationnel ne peut pas échoué. Il utilise les mauvaises abstractions (définies au lieu de l'ensemble commandé).
4 Le système de type limité et le manque de comportement (méthodes de stockage) est responsable de la mauvaise qualité des données observée dans des bases de données relationnelles. 30% des lignes contenant de mauvaises données n'est pas rare
5 fois pour aller dehors et jouer avec les enfants. Il y a plus d'arguments
6 ormes n'ont rien à voir avec OOWBMS.
7 Grands systèmes Construire avec des bases de données relationnelles ne sont jamais correctement normalisés en raison des problèmes de performance lorsqu'ils font beaucoup de jointures.
8 Votre argument de méthode n'est tout simplement pas basé sur des faits
@Stephan: 1) Savez-vous la distinction entre SQL et le modèle / algèbre relationnels? 2) vous devrez être plus précis; Les problèmes que j'ai cités sont assez facilement exprimés en SQL. 3) Je ne comprends pas la déclaration qui définit les choses moins évolutives que les ensembles commandés; Un ordre imposé rend plus difficile l'optimiseur, pas plus facile. J'ai travaillé sur une langue de requête pour un système distribué à Microsoft qui a traité environ 1 TB / min sur les requêtes ad hoc de numérisation complète. L'absence de contraintes de commande était essentielle à la réalisation de cela. 4) le modèle relationnel n'entraîne aucune restriction sur les types; SQL fait.
6 et 8) alors veuillez élucidater; J'ai déclaré que je ne suis pas aussi au faire avec des oodbms comme je suis avec ormes, il serait donc bon d'entendre quelqu'un avec plus d'expérience dans cette zone. Peut-être que j'ai tout faux - et j'apprécie la chance d'apprendre des erreurs, de l'humiliation telle qu'elle est dans un forum public - mais je ne peux pas apprendre d'un fade "tu as tort". 7) le modèle relationnel ne contrainte pas l'organisation physique des données; SQL fait. Un SGBD relationnel peut dénormaliser dans les coulisses basées sur des profils d'utilisation prédits ou mesurés; Toute technique est valide aussi longtemps que l'utilisateur voit toujours les Reliers qu'il a définis.
1 Laissez-moi reformuler que: les implémentations de la base de données SQL. 2 Votre exemple signifie que la table représentant une vente reçoit de plus en plus de colonnes (ou doit utiliser quelque chose comme un schéma d'étoiles) car le système couvre davantage l'entreprise. C'est une mauvaise modélisation. Et cela fonctionne mal. Vous souvenez-vous que l'exemple de DWH ridicule Microsoft a montré avec un modèle de vente 4D et un téraoctet de données? Il y avait une raison pour laquelle il n'avait pas eu de nombre réaliste de dimensions des ventes
6 Gemstone est une machine virtuelle persistante SmallTalk. Vous voudrez peut-être jeter un coup d'œil à Programminggems.wordpress.com/2010 / 02/05 / Scaling-Objects-Vid EOS 8 est simple: il n'est pas implémenté sur le client, il est sur le serveur.
3 Je ne comprends pas pourquoi une analyse complète serait influencée par la commande.
1) pas de désaccord là-bas; Les deux dernières phrases de ma réponse ont couvert cela. 2) Peut-être que je n'ai pas expliqué mon exemple correctement; Il n'est pas nécessaire de développer le schéma. 3) la balayage complète et la commande ne sont pas liées; Je soulignais simplement que le moteur a effectivement consommé tous les données (environ 5-10 To sur une course typique) plutôt que de accélérer les choses avec des index. Nous l'avons fait avec un style de l'entrelacement de carte de carte afin de regrouper les données par les clés. Si le système avait été modélisé sur l'idée des ensembles ordonnés, il aurait été beaucoup plus difficile d'organiser le graphique d'exécution pour optimum Dataflow ...
6) J'ai déjà passé un peu de temps à répondre et à commenter un peu de temps; Je ne veux pas regarder un tas de vidéos. Il est difficile de commenter plus avant de vos revendications en l'absence d'échantillons de code simples. Existe-t-il des échantillons et / ou des tutoriels facilement accessibles en ligne? Ou peut-être que vous pouvez fournir un exemple de la manière dont une ou plusieurs des requêtes que j'ai suggérées seraient résolues dans Gemstone. Les "paires d'employés", on m'intéresse notamment avec son double: "Quelles paires d'immeubles ont plus d'un employé en commun?" 8) point prisé. Je n'étais pas si sûr de cette affaire.
Le tutoriel est chez SeeSide.gemstone.com/Tutorial.html . Les vidéos montrent un peu de détails de mise en œuvre.
Je pense que tout dépend des spécificités de votre problème. (Je sors vraiment sur un membre ici, je sais.)
Tout ce que nous savons, c'est que vous souhaitez utiliser le DB pour le développement Web et vous ferez beaucoup d'opérations sur les données.
L'une des questions pertinentes à poser est de savoir à quel point il est important que la DB soit étroitement intégrée aux objets que vous manipulez? Plus il est nécessaire, plus un DB orienté vers l'objet se recommande.
D'autre part, si vos données se prête facilement au modèle relationnel, une DB relationnelle pourrait être meilleure.
Pensez aux opérations dont vous aurez besoin. Aurez-vous besoin d'une analyse de toutes sortes d'éléments avec différents attributs? Combien aurez-vous besoin de futurs db?
Je devrais ajouter que si votre DB est susceptible d'être assez faible, les performances ne seront pas un problème majeur. Mais si la performance est en fait une question, vous avez beaucoup de choses à craindre au-delà de Just Oo vs. DBS relationnels. (Juste pour choisir un exemple du monde de la DB relationnelle, quelle forme de normalisation devriez-vous utiliser? Il s'agit d'une question extrêmement importante, et complexe, qui maintient un système opérationnel ou un entrepôt de données? Savez-vous à l'avance que certaines requêtes sont d'une importance primordiale, ou d'une importance négligeable? & c.)
Au-delà de la question de la performance et de l'intégration DB avec votre modèle d'objet, il existe d'autres questions du monde réel à poser. Avez-vous des limitations de diskspace / serveur / bande passante? Voulez-vous offrir uniquement un petit nombre d'opérations aux utilisateurs Web, ou des personnes que vous ne savez même pas créer de leurs propres requêtes / modifications?
Pour les autres questions réelles, plus importantes, que vous travaillerez? Que savent-ils déjà (ou préfèrent-ils)? Et si vous n'avez pas encore connaissance domaine, vous avez peut-être une curiosité personnelle vous poussant dans une direction? Si vous commencez sur un projet personnel, vous suivez vos propres préférences, c'est un meilleur guide du succès que de vous inquiéter des performances avant même de commencer.
Si vous pouvez répondre à ces questions et à des questions similaires, même si la réponse est "Je ne sais pas", vous pourrez obtenir une grande meilleure orientation dans la façon de procéder.
contractuel à Marcelo en profondeur et bien pensé à la réponse, je dirais que sur la base de la phrase de votre question "Développement Web régulier", ma réponse à la branche serait de dire que vous seriez difficile pressé pour Trouvez suffisamment de PRO pour justifier à l'aide d'un objet dB sur une DB relationnelle traditionnelle, pour le simple fait que davantage de ressources / développeurs / didacticiels /, etc., qui connaissent mieux le modèle relationnel traditionnel et comment utiliser cela pour atteindre «Développement Web régulier ".
Cela dit, je pense qu'avec certains des ormes modernes, vous obtenez un peu le meilleur des deux mondes, en ce que vos données sous-jacentes sont stockées dans un SGDBR bien compris (probablement stable, supporté, etc.), Mais vous pouvez toujours résumer certaines des capacités de modélisation d'objet qui peuvent (sans doute) être plus adaptées au développement d'applications CRUD.
Je vais admettre que je ne suis pas bien versé dans les capacités actuelles des OOPRM modernes, cependant, à moins que vous n'ayez dans un domaine qui convient parfaitement à une représentation parfaite de votre domaine (et que vous avez le talent de modélisation d'objet Pour profiter), alors je serrerais avec un SGBDM pour votre stockage persistant.
espère que cela aide!
Base de données relationnelle:
Avantages:
contre:
oobdms
Avantages:
contre:
Donner la prime à 23hours - été occupé ces jours-ci :)
Un autre pro pour OOTBMS: peut gérer beaucoup plus de données de données (si vous pouvez vous permettre le prix)
BTW: Couplé avec un cadre ORM (I.E. Hibernate) Les systèmes RDBMS peuvent être utilisés dans un modèle plus naturel aux développeurs, au coût des performances et de la complexité (ils encapsulent l'accès à la DB, mais vous devez apprendre à les utiliser correctement). Les outils ORM sont très matures ces jours-ci et fournissent une bonne solution à certaines des questions introduites par un SGBDM.
"Exprime de nombreux domaines problématiques dans une manière logique et" programmable ""?
Je peux répondre à votre question par rapport à une base de données d'un objet que je connais bien: zodb .
la ZODB vous permet de persister vos modèles de données presque complètement de manière transparente. Son utilisation équivaut à quelque chose comme: Vous devrez regarder longtemps pour trouver ce type de lisibilité avec un RDMBS. Qu'il y ait le Big Pro à l'utilisation de ZODB dans une application Web. Le gros inconvénient, comme les contours de Marcello, le manque de requête puissante. C'est en partie un effet secondaire de la commodité de l'idiome ci-dessus. Ce qui suit est complètement correct et tout va être persisté à la base de données: Cependant, ce type de flexibilité permet d'optimiser des requêtes complexes sur différents modèles. Il suffit de faire une liste de toutes les voitures jaunes avec des voisins nécessitera Donc, cela dépend de ce que vous entendez par "Développement Web régulier" . De nombreux sites Web ne nécessitent pas réellement que des requêtes multidimensionnelles complexes et des recherches dans le temps linéaire ne sont pas un problème. Dans ces cas, l'utilisation d'une SGBDM peut à mon avis sur-compliquer votre code. J'ai écrit de nombreuses applications de type CMS à l'aide de la seule base de données d'objet. Beaucoup de crud ne l'entrent pas particulièrement; ZODB est très mature, et des écailles et des caches assez bien. Cependant, si vous écrivez une application Web qui doit faire des rapports commerciaux complexes dans le sens de Google Analytics, ou une sorte de gestion des stocks d'entrepôt. Système avec de nombreux téraoctets de données, alors vous allez certainement vouloir vouloir un SGBDM. à résumer, une base de données d'objet peut vous donner la lisibilité et la maintenabilité au coût de la performance de la requête complexe. Bien sûr, la lisibilité est une question d'opinion et vous ne pouvez pas ignorer le fait que beaucoup plus de développeurs connaissent SQL que les différents dialectes de la base de données d'objets. o (n) fois si vous ne roulez pas votre propre index.
Dans une owbms normale comme la requête de pierre précieuse est beaucoup plus puissante que dans un SGBDM
Développement Web régulier, j'utilise la mer sur pierre précieuse. Pour la plupart des applications, cela signifie que j'écris zéro code de connexion de base de données. Il effectue, elle échoue, le développement est environ cinq fois plus rapide.
La seule fois où je vais utiliser une base de données relationnelle à nouveau pour le développement Web, c'est quand je dois me connecter à un existant.
Les avantages:
Les dérivations:
contre
contre
Bases de données d'objet-relationnelles (vous avez peut-être vu des UDTS!)
Différentes approches (OO, DB relationnelle ou OODB) peuvent être nécessaires pour différentes applications
L'avantage de l'utilisation de bases de données relationnelles pour les grandes corpora < / p>
Base de données relationnelle de base de données relationnelle
Avantages d'une base de données relationnelle
L'objet - Système de base de données personnalisé Manifeste
Systèmes de base de données orientés objet
Bases de données relationnelles d'objet dans le SGBM
Critères de complétude pour les systèmes de base de données d'objet-relation
comparaisons
http://fr.wikipedia.org/wiki/comparison_of_relation_database_management_systems
http://en.wikipedia.org/wiki/comparison_of_Object_database_management_systems
http://en.wikipedia.org/wiki/comparison_of_Object-relational_database_management_systems < / p>
Aucune fondation mathématique n'est un argument imparfait. Il y a plus aux mathématiques que de la théorie définie. Turing et Dijkstra étaient des mathématiciens.
L'article 'L'avantage de l'utilisation de bases de données relationnelles pour les grandes corpus' ne se compare pas à une OODB. Si je la lisais correctement, c'est un problème qui aurait été beaucoup plus facile de résoudre l'utilisation d'une OODB
«Avantages d'une base de données relationnelle» Noms quatre avantages où une OODB score en fait mieux sur tous ces avantages
Oui, je veux juste signaler les différents cas d'utilisation pour les deux. Pour OODB, il n'y a pas de soutien d'une théorie mathématique définie comme les RDBS. À propos de l'article, généralement les corpus sont définis dans une base de données graphiques (pour la modélisation des relations sémantiques), mais la RDB peut également être utilisée. «Avantages d'une base de données relationnelle» est juste une référence simple
Les données distinctes du programme doivent être répertoriées comme un con pour les SGBD. C'est la raison de la qualité de données faible. Et cela rend l'intégrité référentielle un concept pratiquement inutile.
Totalement d'accord avec les avantages ici. La norme de l'industrie est d'utiliser un ORM + SDBMS.
S'il vous plaît regarder à la technologie sémantique. C'est mon opinion personnelle que Semantic Data Store est supérieur au magasin de données relationnelles. AFA AS OOWBMS est concerné, la technologie ou l'algorithme n'est pas suffisamment mature pour comparer avec les SGBD.
La norme de l'industrie est fausse pour le développement Web régulier. OOWBMS est assez mature: Regardez la durée JP Morgan utilise des pierres précieuses.
Rob conery a une série ( blog.wekeroad.com/category/nosql ) de messages . Celui-ci ici ( blog.wekeroad.com/2010/02/05/ Reporting-in-NOSQL ) parle de l'endroit où les RDBMS ont du sens dans un monde OOTBMS. Et voici un post sur l'utilisation à la fois à la fois: Blog. wekeroad.com/2010/05/19/no-sql-in-the-wild