In der Website von MongoDB haben sie geschrieben, dass MonogDB Dokument-orientierte Datenbank ist, also wenn die MongoDB keine objektorientierte Datenbank ist, also was ist das? und was sind die Unterschiede zwischen dokument- und objektorientierten Datenbanken?Ist MongoDB objektorientiert?
Ich denke, doc-orientierte und objektorientierte Datenbanken sind ziemlich unterschiedlich. Ziemlich detaillierte Post auf diese hier:
Ein Dokument orientierte Datenbank ein anderes Konzept und relationale Datenbanken zu widersprechen. Eine Dokumentendatenbank kann ein Feld enthalten oder nicht, während eine relationale oder Objektdatenbank erwarten würde, dass fehlende Felder mit einem Nulleintrag gefüllt werden.
Stellen Sie sich vor, Sie speichern eine XML- oder JSON-Zeichenfolge in einem einzelnen Feld in einer Datenbanktabelle. Das ist ähnlich wie eine Dokumentendatenbank funktioniert. Es ermöglicht einfach, semistrukturierte Daten in einer Datenbank zu speichern, ohne viele Nullfelder zu haben.
dokumentenorientierte
In meinem Verständnis MongoDB jeden einzelnen Datensatz wie ein Dokument behandelt, egal es ist ein Feld oder n Felder aus. Sie können sogar Dokumente in ein Dokument eingebettet haben. Sie müssen kein Schema definieren, das in anderen relationalen DB-Systemen (MySQL, PorgeSQL etc.) streng kontrolliert wird. Ich habe MongoDB eine Weile benutzt und ich mag seine Philosophie sehr.
Objektorientiert ist ein Datenbankmodell, in dem Informationen in Form von Objekten dargestellt werden, wie sie in der objektorientierten Programmierung (Wikipedia) verwendet werden.
Dies kann ein bisschen spät in der Antwort sein, aber nur gedacht, es ist erwähnenswert, gibt es große Unterschiede zwischen ODB und MongoDB.
Im Allgemeinen konzentriert sich ODB auf transparente Beziehungen (Relationen) zwischen Objekten in einem beliebig komplexen Domänenmodell, ohne Code für einen DBRef verwenden und verwalten zu müssen. Selbst wenn Sie mehrere tausend Klassen haben, brauchen Sie sich keine Gedanken über die Verwaltung von Schlüsseln zu machen. Sie werden kostenlos zur Verfügung gestellt. Wenn Sie zur Laufzeit Instanzen dieser 1000 Klassen erstellen, wird automatisch das Schema in der Datenbank erstellt für Dinge wie ein sich selbst referenzierendes Objekt mit Sammlungen von Sammlungen.
Auch Ihre Transaktionen können diese Referenzen umfassen, sodass Sie kein vollständig eingebettetes Modell verwenden müssen.Die Konzepte sind diejenigen, die in ORM-Lösungen wie JPA, dem verwalteten persistenten Objektlebenszyklus, verwendet werden, aus dem ODB-Raum, aber der RIESIGE Unterschied ist, dass es keine Zuordnung AT ALL in der ODB gibt und Relationen als gespeichert werden Teil der Datenbank so gibt es keine Laufzeit JOIN, um Beziehungen zu lösen, alle Beziehungen werden mit der gleichen Geschwindigkeit wie eine B-Baum-Suche aufgelöst. Für diejenigen unter Ihnen, die Hibernate verwendet haben, stellen Sie sich Hibernate ohne jegliche Mapping-Datei und Größenordnungen schneller vor, da es keine Runtime JOIN hinter den Kulissen gibt.
Außerdem ermöglicht ODB Abfragen über alle Beziehungen in Ihrem Modell, sodass Sie nicht auf Abfragen in einer bestimmten Sammlung beschränkt sind, wie Sie in MongoDB sind. Natürlich werden Hash/B-Tree/Aggregat-Indizes unterstützt, so dass Abfragen sehr schnell sind, wenn sie verwendet werden.
Sie können Instanzen jeder Klasse in einem ODB auf Klassenebene entwickeln, und zur Laufzeit wird die korrekte Klassenversion aufgelöst. Ganz anders als die Art und Weise, wie MongoDB Code verwaltet, um zu entscheiden, wie mit verschiedenen Formen von Blobs (oder Wertobjekten) umgegangen wird, die sich aus der Entwicklung einer schemalosen Datenbank ergeben ... oder den Code schreiben, um jedes Wertobjekt zu besuchen und zu ändern Sie wollten das Schema ändern.
Soweit Partioning geht, denke ich, dass es viel einfacher ist, ein Partitionierungsmodell für ein Domänenmodell zu wählen, das über beliebige Objekte sprechen kann, dann ist es die beste Einbettungsstrategie für Ihre Sammlung enthalten Dokumente in MongoDB. Als ein redliches Beispiel haben Sie einen Kontakt und eine Adresse und ein ShoppingCart und diese sind in einem JSON-Dokument verwandt und Sie beschließen, auf Contact von Contact_id zu partitionieren. Es gibt absolut nichts, was Sie davon abhalten könnte, diese 3 Klassen als nur Objekte anstelle von JSON-Dokumenten zu behandeln und diese mit einer Partition auf Contact_id zu speichern, genau wie mit MongoDB. Wenn Sie jedoch ein anderes Objekt-Konto hatten und diese aufgrund einiger aggregierter Abrechnungsvorgänge für Konten nicht eingebettet haben wollten, können Sie diese kostenlos (ohne Code für einen DBRef-Typ erstellen) in der ODB anlegen ... und Sie können wählen, ob Sie direkt mit dem Kontakt partitionieren möchten oder ob Sie die Accounts in einem komplett separaten physischen Knoten speichern möchten, aber alles wird zur Laufzeit im Anwendungsbereich verbunden ... genau wie Magie.
Wenn Sie ein wirklich cooles Video sehen möchten, wie man eine Anwendung mit einem ODB erstellt, die Verteilung, Objektbewegung, Fehlertoleranz, Leistungsoptimierung anzeigt ... sehen Sie dies (wenn Sie zum coolen Teil springen wollen, springen Sie etwa 21 Minuten, und Sie werden das Gebäude der Anwendung zu vermeiden und nur sehen, die, wie einfach es ist Verteilung und Fehlertoleranz zu einer bestehenden Anwendung hinzugefügt werden):
Vielen Dank Robert für Ihre Antwort, sehr klar und hilfreich. – Amer
ein bisschen späten Kommentars zu alt Antwort - aber mein Verständnis ist auch, dass Sie Einschränkungen für Transaktionen, die sich über viele verschiedene Entitäten/Dokumente erstrecken, nicht wirklich erzwingen können. Zum Beispiel eine Lastschrift von einem Bankkonto, das diesen Betrag dann einem anderen gut schreibt. –