Czym różnią się graficzne bazy danych i obiektowe bazy danych?

Question

Czym różnią się graficzne bazy danych (http://neo4j.org/) od obiektowych baz danych (http://www.db4o.com/)?

Answer 1

Odpowiedź byłaby inna: bazy danych obiektów i wykresów działają na dwóch różnych poziomach abstrakcji.

Główne elementy danych obiektu bazy danych to obiekty, tak jak znamy je z języka programowania obiektowego.

Główne elementy danych w bazie danych wykresów to węzły i krawędzie.

Baza danych obiektów nie ma pojęcia (dwukierunkowej) krawędzi między dwiema rzeczami z automatyczną integralnością referencyjną itp. Baza danych wykresów nie ma pojęcia wskaźnika, który może mieć wartość NULL. (Oczywiście można sobie wyobrazić hybrydy.)

Jeśli chodzi o schemat, schemat bazy danych obiektów jest taki sam jak zestaw klas w aplikacji. Schemat bazy danych wykresów (czy to niejawny, poprzez konwencję oznaczania znaczników String, czy jawnie, przez deklarację jako modele, tak jak robimy to na przykład w InfoGrid) jest niezależny od aplikacji. Dzięki temu znacznie prostsze jest na przykład pisanie wielu aplikacji na tych samych danych przy użyciu graficznej bazy danych zamiast bazy danych obiektów, ponieważ schemat jest niezależny od aplikacji. Z drugiej strony, używając graficznej bazy danych, nie można po prostu wziąć dowolnego obiektu i go utrzymywać.

Różne narzędzia do różnych zadań, które myślę.

Answer 2

Od szybkiego przeglądania obu ich stronach internetowych:

Główną różnicą jest sposób API są tak skonstruowane, zamiast rodzaju free-form bazy danych można zbudować z nimi.

db4o używa mapowania obiektów - tworzysz klasę Java/C# i używa refleksji, aby utrzymać ją w bazie danych.

neo4j ma wyraźny interfejs API do manipulacji.

Neo4j wydawał się, moim skromnym zdaniem, o wiele przyjemniejszy w interakcji.

Można również rozważyć przechowywanie par klucz-wartość - można utworzyć dokładnie taką samą dowolną bazę danych z jedną z nich.

Answer 3

As Will descibes z innego kąta, graphdb będzie przechowywać dane oddzielone od klas aplikacji i obiektów. Graphdb ma również więcej wbudowanych funkcji do obsługi wykresów, oczywiście - jak najkrótsza ścieżka lub głębokie traversals.

Inną ważną różnicą jest to, że w trybie graphdb, takim jak neo4j, można przechodzić przez wykres na podstawie typów (kierunków) relacji i kierunków bez ładowania pełnych węzłów (w tym właściwości/atrybutów węzła). Istnieje również możliwość użycia neo4j jako zaplecza obiektu db, nadal mogącego używać wszystkich elementów graficznych, patrz: jo4neo Ten projekt ma inne podejście, które można również zaliczyć jako obiekt db na szczycie neo4j: neo4j.rb. Nową opcją jest użycie Spring Data Graph, która zapewnia obsługę graphdb przez adnotacje.

To samo pytanie zadano w komentarzach do this blogpost.

Answer 4

Z bazami danych wykresów, masz niewielkie podobieństwo, że jest on oparty na matematycznej teorii grafów. Dzięki zorientowanym obiektowo bazom danych masz pewność, że nie opiera się on na niczym (a na pewno nie ma żadnej teorii matematycznej).

Answer 5

Tak, interfejs API wydaje się być główną różnicą, ale nie jest tak powierzchowny. Pojęciowo zestaw obiektów utworzy wykres i można będzie pomyśleć o interfejsie API, który traktuje ten wykres w jednolity sposób. I odwrotnie, teoretycznie możesz wydobyć ogólną strukturę grafów dla wzorców i odwzorować je na obiekty odsłonięte przez niektóre API. Ale interfejs API rzeczywistego produktu będzie miał zwykle wpływ na to, jak dane są rzeczywiście przechowywane, jak można je sprawdzić, więc na przykład tworzenie wrappera i sprawianie, by wyglądało jak coś innego, nie byłoby banalne. Ponadto zorientowana obiektowo baza danych musi oferować pewne gwarancje integralności oraz strukturę typowania, której normalnie baza danych wykresów nie będzie robić. W rzeczywistości poważna baza danych OO jest daleka od "darmowej formy" :)

Zobacz [HyperGraphDB] [1] - jest to zarówno pełna obiektowa baza danych (jak db4o), jak i bardzo zaawansowana graficzna baza danych pod względem możliwości reprezentacyjnych i zapytań. Jest w stanie przechowywać uogólnione hipergraphy (gdzie krawędzie mogą wskazywać na więcej niż jeden węzeł, a także na inne krawędzie), ma w pełni rozszerzalny system typu osadzony w postaci wykresu itp.

W przeciwieństwie do innych baz danych wykresów, w HyperGraphDB każdy obiekt staje się węzłem lub krawędzią na wykresie, bez ingerencji API typu "minimum-to-minimal" i masz możliwość wyboru reprezentowania twoich obiektów jako wykresu lub traktowania ich w sposób ortogonalny względem struktury wykresu (jako "ładunek") wartości twoich węzłów lub krawędzi). Możesz wykonywać zaawansowane operacje, dostosowywać indeksowanie i sprawdzać zapytania.

Wyjaśnienie, dlaczego HyperGraphDB jest w rzeczywistości ODMS, zobacz wpis na blogu Czy HyperGraphDB jest bazą danych OO? na stronie internetowej Kobrix.

Answer 6

Różnica na niskim poziomie nie jest tak duża. Oba zarządzają relacjami jako bezpośrednimi łączami bez kosztownych połączeń. Ponadto oba mają sposób na przechodzenie przez relacje z językiem zapytań, ale baza danych wykresów ma operatorów do rekursywnego przejścia na poziom N-ty.

Ale największa różnica jest w domenie: w bazie danych Graph wszystko opiera się na 2 typach: wierzchołkach i krawędziach, nawet jeśli zwykle można zdefiniować własne typy jako rodzaj podtypów wierzchołków lub krawędzi.

W ODBMS nie masz żadnych koncepcji wierzchołków i krawędzi, chyba że sam napiszesz.