Webentwicklung - Objekt DB gegen relationale DB

StackOverflow https://stackoverflow.com/questions/5358131

Frage

Was ist die Nachteile und Profis bei der Verwendung einer Objektdatenbank oder einer relationalen Datenbank für die reguläre Webentwicklung, die viel CRUD betrifft?

Update: Ich habe die Kopfgeldbelohnung wieder geöffnet, um Neville zu geben.

War es hilfreich?

Lösung

Relationale Datenbank:

Profis:

  • Etablierte Technologie - Viele Tools, Entwickler, Ressourcen
  • Großes Angebot an Open Source- und kommerziellen Produkten
  • Bekannt als skaliert auf sehr große Standorte und einen sehr hohen Durchsatz
  • Drückt viele Problemdomänen auf logische und "programmierbare" Weise aus
  • Fair Standard Language (SQL)

Nachteile:

  • Impedanzfehlanpassung mit OO -Konzepten - Modellierung "Vererbung" in einer Datenbank ist nicht natürlich
  • Hierarchische Strukturen erfordern normalerweise perborenspezifische Erweiterungen in die Sprache
  • Nicht-relationale Daten (z. B. Dokumente) sind keine natürliche Passform
  • Änderungen im Geschäftsbereich können schwer zu implementieren sein, sobald das Schema definiert wurde

Oobdms

Profis:

  • Enger für oo -Konzepte geeignet
  • Theoretisch muss ein Entwickler nur in einer Sprache arbeiten - die Persistenzdetails werden abstrahiert. Dies sollte die Produktivität verbessern

Nachteile:

  • Wesentlich weniger Tools/Ressourcen/Entwickler verfügbar.
  • Keine weithin anerkannten Standards
  • "Black Box" -Ansatz zur Persistenz kann die Leistungsstimmung erschweren
  • Persistenzdetails lagen oft in das OO -Design ein (siehe Beispiele von Marcelo)

Andere Tipps

Das Konzept eines OoDBMS ist ziemlich kaputt, und die verschiedenen kommerziellen und kostenlosen Angebote, die in den letzten Jahrzehnten aufgetreten sind, haben auf dem Markt kaum einen DINT gemacht.

Das relationale Modell ist in Bezug auf die Arten von Fragen, die Sie Ihrer Daten stellen können, leistungsfähiger als Objektmodelle. Leider warf SQL viel aus der ausdrucksstarken Leistung, zu der das relationale Modell fähig ist, aber selbst in dieser verdünnten Form ist es immer noch einfacher, Abfragen in SQL auszudrücken als in einer typischen OO -Datenbank (sei es Orm oder OODBMS).

Abfragen in einem OODBMS werden überwiegend von Navigationsbetreibern angetrieben. Wenn in Ihrer Verkaufsdatenbank Vertriebsmitarbeiter ihre Verkäufe besitzen, ist es wahrscheinlich nicht nur, dass die monatlichen Verkäufe für eine bestimmte SKU nicht nur langsam langsam, sondern sehr umständlich sein, um es auszudrücken. Betrachten Sie auch ein Sicherheitsmodell, das den Mitarbeitern Zugang zu Gebäuden gewährt. Welches ist der richtige Weg, um dies auszudrücken? Sollten Mitarbeiter eine Sammlung von Gebäuden abhalten, auf die sie zugreifen können, oder sollten Gebäude eine Sammlung von Mitarbeitern enthalten, die Zugang zu ihnen haben? Mehr auf den Punkt, warum sollte eine der beiden Klasse eine Sammlung des anderen in ihr Design eingebacken haben? Und wie auch immer Sie wählen, wie würden Sie fragen, welche Mitarbeiterpaare mehr als ein Gebäude haben, auf das sie gemeinsam zugreifen können? Es gibt kein einfaches Navigationsmuster, das eine solche Frage beantworten kann. Die vernünftige Lösung-ein "Zugriffsobjekt-ist im Wesentlichen eine Umkehrung zu einem ordnungsgemäß normalisierten relationalen Schema und erfordert eine Art Abfragesprache, die sich stark von der relationalen Algebra auswirkt, um die Frage ohne massive Over-the- Drahtdatenübertragung.

Betrachten Sie auch eine weitere wichtige Stärke, die für die OODBMS angepriesen wurde: Methoden, insbesondere Vererbung mit virtuellen Methoden. Eine Sportklinik kann für verschiedene Arten von Athleten unterschiedliche Metriken des Verletzungsrisikos haben. In der ORM -Welt würde dies automatisch als Klassenhierarchie ausgedrückt, mit Athlete am Wurzel und eine virtuelle Methode, int InjuryRiskScore() implementiert von jeder abgeleiteten Klasse. Das Problem ist, dass diese Methode ausnahmslos auf dem Kunden implementiert wird, nicht am hinteren Ende. Wenn Sie also die 10 Sportler mit den 10 höchsten Risiken in allen Sportarten in Ihrer Klinik finden möchten, können Sie alle Athleten über die Abrufen abrufen Verdrahten und durch eine kundenseitige Prioritätswarteschlange führen. Ich kenne auch die OODBMS -Welt nicht, aber ich denke, dasselbe Problem tritt auf, da die Speichermotoren im Allgemeinen nur genügend Daten speichern, um Objekte in der Programmiersprache des Kunden zu rehydrieren. Im relationalen Modell oder SQL würden Sie eine Einnahmerisiko als Ansicht ausdrücken, die einfach die Vereinigung von Ansichten vom Typ Per-Athleten sein könnte. Dann stellen Sie einfach die Frage. Oder Sie können kompliziertere Fragen wie "Wer hat die größte Erhöhung ihres Verletzungsrisikos seit dem Untersuchung des letzten Monats?" Oder sogar: "Welcher Risikowert hat sich als der beste Prädiktor für Verletzungen im letzten Jahr erwiesen?". Am wichtigsten ist, dass diese Fragen alle in den DBMs mit nichts weiter als der Frage und der Antwort beantwortet werden können, die über den Draht wandert.

Das relationale Modell ermöglicht es den DBMs, Wissen auf basierend auf der Prädikatlogik auszudrücken, die die verschiedenen Abmessungen der darin gespeicherten Fakten ermöglicht Benehmen. Sie können die Daten einfach auf eine Weise kochen, die nicht erwartet wurde, wann das System ursprünglich entworfen wurde. Das relationale Modell ermöglicht somit den reinsten Ausdruck von Wissen, von dem wir wissen. Kurz gesagt, das relationale Modell enthält reine Tatsachen - nichts mehr, nichts weniger (und sicherlich nicht Objekte oder Proxys davon).

In historischer Hinsicht entstand das relationale Modell als Reaktion auf einen katastrophalen Zustand mit dem vorhandenen Netzwerk und hierarchischen DBMS der Zeit und verdrängte sie weitgehend (und zu Recht) für alle bis auf eine kleine Nische von Anwendungsgebieten (und sogar diese wahrscheinlich diese wahrscheinlich blieb größtenteils, weil SQL die RMS -Leistung nicht liefern konnte. Es ist zutiefst ironisch, dass sich ein Großteil der Branche nun im Wesentlichen nach den "guten alten Zeiten" von netzwerk-theoretischen Datenbanken sehnt. Diese Bemühungen kritisierten SQL zu Recht dafür, dass sie die heutigen Bedürfnisse nicht erfüllt, aber leider haben sie (fälschlicherweise und wahrscheinlich aus reiner Unwissenheit) angenommen, dass SQL eine hohe Ausdrucksausdruck des relationalen Modells ist. Daher versäumten sie es, das relationale Modell selbst zu berücksichtigen, das praktisch keine der Einschränkungen hat, die so viele von SQL weggetrieben haben, oft in Richtung OODBMSS.

Ich kann Ihre Frage in Bezug auf eine Objektdatenbank beantworten, die ich gut kenne: Zodb.

Mit dem ZODB können Sie Ihre Datenmodelle fast vollständig transparent bestehen. Die Nutzung entspricht so etwas wie:

 # 'Persistent' allows us to save things transparently
 class Car(Persistent):
   def set_wheels(number)
      self.wheels = number

 # 'database' is a ZODB database
 database.car = Car()
 database.car.set_wheels(3)

Sie müssen lange nachsehen, um diese Art der Lesbarkeit mit einem RDMBS zu finden. Dass es das große Profi gibt, ZODB in einer Webanwendung zu verwenden.

Der große Nachteil, wie Marcello surft, ist das Fehlen einer starken Abfrage. Das ist teilweise ein Nebeneffekt der Bequemlichkeit der oben genannten Idiom. Das Folgende ist völlig in Ordnung, und alles wird in der Datenbank bestehen:

 database.car.colour = "yellow"
 database.car.owner = "Trotter"
 database.car.neighbour = Car()

Diese Art der Flexibilität macht es jedoch schwierig, komplexe Abfragen über verschiedene Modelle hinweg zu optimieren. Wenn Sie nur die Liste aller gelben Autos mit Nachbarn erstellen O(n) Zeit, es sei denn, Sie rollen Ihren eigenen Index.

Es hängt also davon ab, was Sie mit "regulärer Webentwicklung" meinen. Viele Websites erfordern keine komplexen mehrdimensionalen Abfragen und die Suchanfragen in linearer Zeit sind überhaupt kein Problem. In diesen Fällen kann die Verwendung eines RDBMs meiner Meinung nach Ihren Code überkomplizieren. Ich habe viele Anwendungen vom CMS-Typ mit nur einer Objektdatenbank geschrieben. Viel Crud kommt nicht besonders insbesondere; ZODB ist sehr ausgereift und skaliert und schneidet ziemlich gut.

Wenn Sie jedoch eine Webanwendung schreiben, in der komplexe Geschäftsberichte im Rahmen von Google Analytics oder eine Art Lagerinventarverwaltungssystem mit vielen Terabyte von Daten durchgeführt werden müssen, möchten Sie auf jeden Fall ein RDBMS.

Zusammenfassend lässt sich sagen, dass eine Objektdatenbank Ihnen Lesbarkeit und Wartbarkeit auf Kosten komplexer Abfrageleistungen lesbar machen kann. Natürlich ist die Lesbarkeit eine Frage der Meinung, und Sie können die Tatsache nicht ignorieren, dass sehr viele weitere Entwickler SQL kennen als die verschiedenen Objektdatenbank -Dialekte.

In regelmäßiger Webentwicklung verwende ich Seaside auf Gemstone. Für die meisten Anwendungen bedeutet dies, dass ich Null -Datenbankverbindungscode schreibe. Es wird ausgeführt, es skaliert, die Entwicklung ist ungefähr fünfmal schneller.

Das einzige Mal, dass ich jemals eine relationale Datenbank für die Webentwicklung verwenden werde, ist, wenn ich eine Verbindung zu einem vorhandenen herstellen muss.

Die Vorteile:

  • weniger Code, schnellere Entwicklung;
  • viel bessere Skalierbarkeit;
  • kann viel komplexere Modelle bewältigen;
  • viel bessere Projektagilität;
  • Habe ich Flexibilität erwähnt;
  • Kann Änderungen in Klassenmodellen und nicht nur Daten, sondern auch Code bewältigen.

Die Verabreichungen:

  • Sie müssen wahrscheinlich Entwickler selbst ausbilden.
  • Der, den Sie möchten (Edelstein), kostet ein ernstes Geld für große Systeme

Relational DB

  • SQL und Standards
  • leicht zu modellieren
  • kann nur Standard- und Verkäufertypen verwenden
  • Referenzintegrität (Matematisch solide Relationale Set -Theorie)
  • Viele Tools und Datenbankimplementierungen
  • Daten, die vom Programm getrennt sind
  • Speichermanagement und High -End -Infrastrukturunterstützung
  • Transaktions- und Parallelitätsmanagement innerhalb
  • Das relationale Modell ist wertbasierte IE-Zeilen werden durch Primärschlüssel identifiziert

Nachteile

  • Kein benutzerdefinierter Typ
  • Keine erweiterbaren Datentypen
  • Impedanzfehlanpassung
  • kann eine verschachtelte Beziehung nicht ausdrücken
  • Es kann keine komplexen Entitäten als einzelne Einheit verwenden
  • müssen Schlüssel und verschiedene Arten von Beziehungen auf Datenmodellebene definieren
  • Schreiben Sie Verfahren für die Versionierung, Transaktionen bei Bedarf

Objekt DB

  • Hochleistung
  • Schneller, da keine Verbindungen erforderlich sind
  • Inhärenter Versionungsmechanismus
  • Navigationsschnittstelle für Operationen (wie Graph -Traversal)
  • Objektabfrage Sprache abrufen Objekte deklarativ
  • Komplexe Datentypen
  • Objektidentität dh. Equals (), in der Objektidentität unabhängig von Wert und Aktualisierungen ist
  • Erleichtert das Teilen von Objekten
  • Klassen und Hierarchien (Vererbung und Kapselung)
  • Unterstützung für Beziehungen
  • in eine Persistenzsprache wie ODL integriert
  • Unterstützung für Atomizität
  • Unterstützung für verschachtelte Beziehungen
  • Semantische Modellierung

Nachteile

  • Keine mathematische Grundlage als RDB (siehe Codd)
  • Nachteile der Objektorientierung
  • Persistenz für komplexe Strukturen schwierig, einige Daten müssen vorübergehend sein

Objektrelationsdatenbanken (Vielleicht haben Sie UDTS gesehen!)

  • Unterstützung für komplexe Datentypen wie Sammlung, Multisets usw.
  • objektorientierte Datenmodellierung
  • erweiterte SQL und reiche Typen
  • Unterstützung für die UDT -Inhetzung
  • kraftvolle Abfragesprache

Für verschiedene Anwendungen können verschiedene Ansätze (OO, relationales DB oder OODB) erforderlich sein

Verweise

Der Vorteil der Verwendung von relationalen Datenbanken für große Korpora

Relationale Datenbank Relationale Datenbank

Oodms Manifest

ODMG

Vorteile einer relationalen Datenbank

Das objektorientierte Datenbanksystem Manifesto

Objektorientierte Datenbanksysteme

Relationale Objektdatenbanken in DBMs

Vollständigkeitskriterien für Objektrelationsdatenbanksysteme

Vergleiche

http://en.wikipedia.org/wiki/comparison_of_relational_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

Ich denke, dass alles von den Einzelheiten Ihres Problems abhängt. (Ich weiß, ich weiß wirklich auf einem Glied.)

Wir wissen nur, dass Sie die DB für die Webentwicklung verwenden möchten, und Sie werden viele Vorgänge für die Daten ausführen.

Eine der relevanten Fragen, die Sie sich stellen sollten, ist, wie wichtig ist es, dass die DB eng in die von Ihnen manipulierten Objekte integriert wird. Je mehr es notwendig ist, desto mehr empfiehlt sich ein objektorientierter DB.

Wenn sich Ihre Daten hingegen leicht für das relationale Modell eignen, ist eine relationale DB möglicherweise besser.

Denken Sie an die Operationen, die Sie ausführen müssen. Benötigen Sie eine Analyse aller möglichen Elemente mit unterschiedlichen Attributen? Wie viel benötigen Sie, um Ihre DB zukünftig zu beachten?

Ich sollte hinzufügen, dass, wenn Ihre DB wahrscheinlich ziemlich klein ist, die Leistung kein großes Problem darstellt. Aber wenn die Leistung tatsächlich ein Problem ist, haben Sie viele Dinge, über die Sie sich über nur noch relationale DBs kümmern müssen. (Welches Normalisierungsformular sollten Sie nur ein Beispiel aus der relationalen DB -Welt auswählen? Dies ist eine äußerst wichtige und komplexe Frage. Behalten Sie ein Betriebssystem oder ein Data Warehouse auf? Wissen Sie im Voraus, dass bestimmte Abfragen sind von größter Bedeutung oder von vernachlässigbarer Bedeutung? & c.)

Über die Frage der DB-Leistung und -integration in Ihr Objektmodell hinaus sind andere Fragen der realen Welt zu stellen. Haben Sie Diskspace / Server- / Bandbreitenbeschränkungen? Werden Sie Webnutzern nur eine kleine Anzahl von Vorgängen anbieten oder Personen, von denen Sie nicht einmal wissen, dass sie ihre eigenen Fragen/Änderungen erstellen?

Mit wem arbeiten Sie für andere, wichtigere Fragen der realen Welt? Was wissen sie bereits (oder bevorzugen sie)? Und wenn Sie noch kein Domain -Wissen haben, haben Sie vielleicht persönliche Neugier, Sie in eine Richtung zu drängen? Wenn Sie mit einem persönlichen Projekt beginnen, ist es ein besserer Leitfaden für den Erfolg als die Sorgen um die Leistung, bevor Sie überhaupt beginnen.

Wenn Sie diese und ähnliche Fragen beantworten können, auch wenn die Antwort "Ich weiß nicht" lautet, können Sie in der Lage sein, eine viel bessere Richtung in die Vorgehensweise zu erhalten.

In Vertrag an Marcelos Tiefe und gut durchdachte Antwort würde ich sagen, dass meine Frage, die auf der Formulierung Ihrer Frage "reguläre Webentwicklung" ist, meine Reaktion von Manschetten darstellt, dass Sie schwer zu finden sind, genug Profi zu finden Um die Verwendung eines Objekt -DB über eine herkömmliche relationale DB zu rechtfertigen, sind es einfacher Ressourcen/Entwickler/Tutorials/usw., die mit dem herkömmlichen relationalen Modell besser vertraut sind und wie man diese nutzt, um "regelmäßige Webentwicklung" zu erreichen.

Ich denke jedoch, dass Sie mit einigen der modernen Orme ein wenig von den Besten aus beiden Welten erhalten, da Ihre zugrunde liegenden Daten in einem gut verstandenen RDBMs gespeichert sind (das ist wahrscheinlich stabil, unterstützt usw.), aber Sie können können Nach wie vor einige der Funktionen der Objektmodellierungsfunktionen abstrahieren können, die (wohl) eher für die Entwicklung von CRUD -Anwendungen geeignet sein können.

Ich gebe zu, dass ich mit den aktuellen Fähigkeiten des modernen OODBMS nicht gut vertraut bin. ), dann würde ich mich bei einem RDBM für Ihren anhaltenden Speicher halten.

Ich hoffe, das hilft!

Dies erklärt ziemlich genau die Vor- und Nachteile:

http://en.wikipedia.org/wiki/object_database

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top