Warum sind Beziehungsdatenbanken häufiger als objektorientierte Datenbanken?Warum sind OODBMS nicht so verbreitet wie RDBMS?
Wenn das Paradigma der objektorientierten Programmierung so weit verbreitet ist, sollten wir nicht viele OODBMS sehen? Wären sie nicht besser als das RDBMS + OR/M?
Ein Grund, warum RDBMS Popularität beibehalten hat, ist, dass es etablierte Technologie ist, gut verstanden und hat eine Standardsprache (SQL), die mehrere Anbieter unterstützen. Es hat auch ein paar gute Schnittstellen wie ODBC und JDBC, die es ziemlich gut mit verschiedenen Sprachen verbinden. Eine stabile API ist ein starker Faktor, um eine Technologie dominant zu halten.
Im Gegensatz dazu gibt es kein klares Modell für OODBMS, weder eine Standardsprache noch eine Standard-API. Es gibt nicht einmal einen De-facto-Standard durch eine führende Anbieterimplementierung.
Das OODBMS-Konzept könnte Leistung besser als RDBMS + ORM. Es hängt ganz von der Implementierung ab. Aber es stimmt auch, dass OODBMS nicht die gleichen Probleme lösen, die RDBMS gut lösen können. Einige Datenverwaltungsaufgaben sind viel einfacher, wenn Sie über referenzielle Integrität und relationale Header verfügen, die von der Datenverwaltungslösung erzwungen werden. Diese Merkmale fehlen im OODBMS-Modell (zumindest bisher).
Es gibt eine Menge Lärm in Blogs, dass relationale Datenbanken veraltet sind, aber RDBMS sind dennoch die beste Allzwecklösung für die große Mehrheit der Datenmanagementaufgaben.
Ich denke, es ist ein Fall von
Wenn es nicht kaputt ist es nicht ändern.
Relationale Datenbanken sind extrem tief verwurzelt.
In einem Wort Interoperabilität (großes Wort an einem Freitag Abend <G>)
Die meisten Unternehmen haben mit Legacy-Systemen auf RDBMS laufen zu arbeiten. Wenn sie OODBMS verwenden, benötigen sie für bestimmte Funktionen weiterhin Zugriff auf RDBMS. Es ist einfacher, eine Art des Zugriffs auf Daten als zwei beizubehalten.
Wenn Sie große Namen wie Oracle und SQL Server in der OODBMS-Welt und bewährte Leistung in einer Vielzahl von Umgebungen haben, dann werden Sie mehr Projekte sehen, die diese verwenden.
Daten leben oft länger und sind wichtiger als Programm. Selbst wenn Sie heute eine Greenfield-Entwicklung beginnen, müssen Sie das Gesamtbild berücksichtigen. Es gibt mehr Werkzeuge, Prozesse und erfahrene Leute, die mit RDBM-Systemen arbeiten. Denken Sie über das Programm hinaus nach: Kapazitätsplanung, Data Mining, Reporting, ETL, Integration mit anderen Datenquellen usw. Wie wäre es mit Ihrem Unternehmen, ein anderes Unternehmen zu erwerben und damit alle relationalen Daten in Ihr Programm zu integrieren? RDBMS und zugehörige Tools sind so fest verwurzelt, bewährt und leistungsfähig, dass es keinen strategischen Sinn gibt, etwas anderes zu verwenden. In einer kleinen Nische vielleicht aber nicht im Allgemeinen.
"Daten leben oft länger und sind wichtiger als Programm." - Amen. Mittlere Stufen kommen und gehen, aber Daten leben für immer. – duffymo
OODBMS impliziert nicht, dass sie an eine bestimmte Sprache gebunden sind, genauso wenig wie RDBMS an implementierungsspezifische gespeicherte Prozeduren gebunden sind. –
In der Theorie haben Sie Recht, aber in der Praxis gibt es nur wenige bekannte RDBMS-Implementierungen, die von Tools, einer umfangreichen Wissensbasis und erfahrenen Mitarbeitern gut unterstützt werden. Meine Firma ging gerade durch eine Unternehmensfusion und wir importierten Daten von der Datenbank des anderen Unternehmens in unsere Datenbank (mit viel Umwandlung, Datenmasse und Reinigung). Beide Unternehmen nutzten Oracle, und das machte die Sache sicherlich einfacher, als wenn das andere Unternehmen eine wenig bekannte Datenbank verwendete. – softveda
Objektdatenbanken haben eine sehr nette Nische für Probleme wie die Darstellung von Geometrie, z. CAD-Systeme, wo Objektgraphen tatsächlich sehr tief sein können. Die JOIN-Leistung verschlechtert sich in den meisten relationalen Systemen für ungefähr 7 Tabellen schnell, so dass tief-selbst-referentielle Strukturen in CAD in Objektdatenbanken besser funktionieren.
Aber wichtige Anwendungen wie Finanzdaten eignen sich für eine relationale Darstellung. Das relationale Modell hat eine feste mathematische Basis und SQL ist eine erfolgreiche und populäre Sprache. Für Finanzinstitute wie Banken, Makler und Versicherungen besteht wenig Anreiz, von RDBMS abzuweichen.
Das größte Problem, das ich gesehen habe, ist der Mangel an Standardisierung. In der RDBMS-Welt kann man mit jeder beliebigen Datenbank ziemlich weit kommen, wenn man SQL kennt. Sie implementieren es im Grunde alle mit kleinen Abweichungen. Ich kenne kein einziges existierendes RDBMS, das nicht mit SQL arbeitet: Sie können "RDBMS" und "SQL" fast synonym verwenden.
Die nächste Sache für ein OODBMS ist vielleicht OQL, was ein völliger Fehler war.
Keine Datenbank hat jemals sehr viel davon implementiert. Ich habe vor ein paar Jahren ein ziemlich nettes kommerzielles OODBMS verwendet, aber es hat (ab 2007 oder so, und es war in der Hauptversion 8 oder 9) nicht einmal die Abfrage eines Objekts nach seinem Namen unterstützt. Das Handbuch sagte einfach, dass sie diesen Teil von OQL noch nicht erreicht hatten. (Ich bin mir nicht sicher, aber Sie könnten in einen nativen Anruf um dies zu tun haben).
Die meisten Objektdatenbanken, die ich kürzlich gesehen habe, haben native Sprachschnittstellen und keine Abfragesprache wie OQL. Das System, das ich verwendete, unterstützte zum Beispiel (nur!) Perl und VB, IIRC. Wenn Sie Ihre Zielgruppe auf nur ein paar Sprachen beschränken (oder sie zwingen, Wrapper zu schreiben, wie wir es getan haben), ist das nicht der Weg, Freunde zu gewinnen.
Aus diesem Grund gibt es keine Konkurrenz und daher keinen einfachen Backup-Plan. Wenn Sie Ihre Daten in MS-SQL ablegen und Microsoft diese nicht mehr unterstützt, können Sie Ihre Daten wahrscheinlich ohne Probleme in Postgres übertragen und Ihre Abfragen portieren. (Es könnte eine Menge Arbeit sein, wenn Sie viele Fragen haben, aber ich zweifle nicht, dass Sie es tun könnten. Es ist ein Schmerz, aber keine technische Herausforderung.) Oder Oracle oder MySQL oder viele andere, beide kommerziell und frei.
So etwas gibt es bei einem OODBMS nicht: Wenn das, was du benutzt, bleach-up geht oder es in eine Richtung führt, die dir nicht nützt, oder du findest, dass es eine wichtige Funktion fehlt, kannst du Töte deine Daten nicht einfach in einem konkurrierenden OODBMS und portiere deine Anfragen. Sie sprechen stattdessen davon, eine Kernbibliothek zu ändern und massive Architekturänderungen vorzunehmen. Sie sind also realistisch auf ein kommerzielles OODBMS beschränkt, dem Sie wirklich vertrauen (können Sie auch nur eins nennen?), Oder auf ein Open-Source-OODBMS, dem Sie vertrauen, dass Ihr Team es bei schlechtem Zustand erhält.
Wenn das klingt wie FUD, sorry, ich hatte nicht die Absicht. Aber ich war dort und aus Sicht des Projektmanagements zögere ich zurückzugehen, obwohl die Programmierumgebung wunderbar sein kann. Eine andere Art, darüber nachzudenken, ist: Schau dir an, wie populär funktionale Programmierung heute ist, obwohl es eine gute Idee ist. OODBMS sind so, aber schlimmer, da es nicht nur dein Code ist, sondern dein Code und deine Daten. Ich würde heute gern ein größeres Projekt in Erlang beginnen, aber ich würde immer noch zögern, ein OODBMS zu verwenden.
OODBMS-Anbieter: Um dies zu ändern, müssen Sie make it easy to leave you for your competitors. Sie könnten OQL ausgraben und das tatsächlich implementieren, oder Sie tun es auf der API-Ebene wie ODBC oder was auch immer. Sogar ein Standard-Dump-Format (mit JSON?) Und Tools für den Import/Export von/für mehrere OODBMS, wäre ein guter Anfang.
Für Tribal Beispiele können OODBs und RDBs sehr unterschiedlich sein. Vor allem, wenn Sie mit einer kleinen Menge an Daten arbeiten, können Sie alles gleichzeitig im Speicher ablegen und es auf einmal ausgeben. Aber letztendlich müssen OODB Daten in einem sehr RDB-ähnlichen Format speichern - sie sind nicht so verschieden.
Betrachten Sie ein beliebiges Diagramm von Objekten, wie es in einer Anwendung verwendet werden könnte. Jedes Objekt kann von mehreren anderen Objekten referenziert werden.Wenn Sie ein Objektdiagramm speichern, möchten Sie Objekte nicht jedes Mal erneut speichern, wenn sie referenziert werden. Zum einen, wenn Sie irgendeine Art von Schleife oder Selbstreferenz haben würden, würde Ihre Speicherobjektmethode in eine Endlosschleife gehen. Aber im allgemeinen Fall ist es eine Platzverschwendung. Stattdessen muss jeder bedeutende Datenspeicher eine eindeutige Kennung für jedes gespeicherte Objekt deklarieren (ein Schlüssel, normalerweise ein Ersatzschlüssel in den RDBMS-Bedingungen). Jedes andere Objekt, das darauf verweist, speichert den Objekttyp und den Schlüssel, es speichert das gesamte Objekt nicht wiederholt. Hier haben wir also Fremdschlüssel in unserem Nicht-RDB-Objektspeicher erstellt.
Als nächstes geben Sie vor, dass wir eine Liste von Objekten (A1, A2, A3 ...) speichern möchten, die zu einem anderen Objekt (B) gehören. Wir haben bereits festgestellt, dass wir Schlüssel speichern werden, anstatt die Objekte selbst zweimal zu speichern. Aber speichern Sie die Schlüssel zu Objekten A1, A2, A3 ... auf Objekt B, oder speichern Sie den Schlüssel zu Objekt B auf A? Wenn Sie sie auf die erste Art und Weise speichern und Sie alle A haben, die Sie wollen, können Sie schnell die relevanten Bs holen. Der zweite Weg ist das Gegenteil. Aber so oder so ist eine Einbahnstraße. Wenn Sie das Umgekehrte von dem, was Sie gespeichert haben, abfragen möchten und Ihre Objekte als XML oder JSON gespeichert werden, ist das ein ineffizientes Parsen durch die meisten irrelevanten Informationen, um den Schlüssel in jeder Datei zu finden. Wäre es nicht besser, sie in einem Format zu speichern, in dem jedes Feld wie Spalten in einer Tabelle getrennt war?
In einer Viele-zu-Viele-Beziehung oder in einem Fall, in dem Sie eine große Anzahl von Objekten in beiden Richtungen finden müssen, wird diese Strategie sehr ineffizient. Die einzige performante Lösung besteht darin, ein Hilfsobjekt zum Speichern der Beziehung zu machen, mit einer Datei für jede Beziehung, so dass die Datei aus dem Schlüssel von A und dem Schlüssel von B besteht, so dass sie schnell nachgeschlagen werden können. Wir haben gerade die Querverweistabelle neu erfunden.
Tabellen mit Spalten, eindeutigen Bezeichnern (Schlüsseln), Querverweistabellen ... Dies sind die grundlegenden Anforderungen für die effiziente Speicherung von Objekten. Hmm ... Klingt das nach etwas Bekanntem? Eine relationale Datenbank bietet genau diese Funktionalität. Darüber hinaus konkurrieren mehrere Anbieter seit Jahrzehnten um die schnellste Datenspeicherung und -wiederherstellung mit den besten Tools für Backup, Replikation, Clustering, Abfragen usw. Das ist eine Menge für eine neue Technologie, mit der man konkurrieren kann. Und schließlich sage ich, dass RDBMS grundsätzlich eine wirklich gute Lösung für das Problem der effizienten Objektspeicherung sind.
Aus diesem Grund gibt es so etwas wie Hibernate - um eine objektorientierte Schnittstelle auf ein effizientes RDBMS-Speichersystem zu setzen. Wo Sie andere Arten von Speichern sehen wirklich glänzen sind verschiedene Problembereiche:
OODBs können nicht besser als RDBs sein, weil sie nicht grundlegend anders sind.
RDBs sind hier, um zu bleiben, weil das Speichern großer Grafiken von Objekten auf eine Weise platzsparend und zeiteffizient sowohl zum Speichern als auch zum Abrufen sowie fehlertolerant ist und eine gewisse Sicherheit der Datenintegrität bietet in erster Linie lösen. Deshalb werden JPA und Hibernate auch hier bleiben - weil sie die Lücke zwischen dem Objekt und den relationalen Modellen von Daten überbrücken. Objektmodell für einfache Manipulation im Speicher und relational für Persistenz.
"Wenn es nicht kaputt ist, ändern Sie es nicht" ist so dumm ... warum macht etwas besser, oder die Entwicklung von Software schneller eine schlechte Sache. Mein letzter Computer war nicht kaputt, als ich ihn änderte, es war einfach LANGSAM !!!Das Streben nach besseren, effizienteren Lösungen ist mein Ziel als Entwickler. – billy