Qual è la differenza tra i database basati su grafici (http://neo4j.org/) e i database orientati agli oggetti (http://www.db4o.com/)?Qual è la differenza tra database basati su grafici e database orientati agli oggetti?
Mi piacerebbe rispondere in modo diverso: database di oggetti e grafici operano su due diversi livelli di astrazione.
Gli elementi dati principali di un database di oggetti sono oggetti, il modo in cui li conosciamo da un linguaggio di programmazione orientato agli oggetti.
Gli elementi di dati principali del database grafico sono nodi e spigoli.
Un database di oggetti non ha la nozione di un bordo (bidirezionale) tra due cose con integrità referenziale automatica ecc. Un database grafico non ha la nozione di un puntatore che può essere NULL. (Naturalmente si possono immaginare ibridi.)
In termini di schema, lo schema di un database di oggetti è qualunque sia l'insieme di classi nell'applicazione. Lo schema di un database grafico (sia implicito, per convenzione di cosa significano le etichette String, o esplicito, per dichiarazione come modelli come lo facciamo in InfoGrid per esempio) è indipendente dall'applicazione. Ciò rende molto più semplice, ad esempio, scrivere più applicazioni rispetto agli stessi dati utilizzando un database grafico invece di un database oggetto, poiché lo schema è indipendente dall'applicazione. D'altra parte, usando un database grafico non puoi semplicemente prendere un oggetto arbitrario e persistere.
Diversi strumenti per diversi lavori vorrei pensare.
Da una rapida occhiata di entrambi i loro siti web:
La differenza principale è il modo in cui le API sono strutturati, piuttosto che il tipo di database di forma libera si può costruire con loro.
db4o utilizza una mappatura di oggetti: si crea una classe Java/C# e si utilizza la reflection per mantenerla nel database.
neo4j ha un'API di manipolazione esplicita.
Neo4j sembrava, a mio modesto parere, molto più bello con cui interagire.
Si potrebbe anche considerare un archivio di valori-chiave: è possibile creare esattamente lo stesso database in formato libero con uno di questi.
Come Descriverà da un'altra angolazione, un graphdb manterrà i dati separati dalle classi e dagli oggetti dell'applicazione. Un graphdb ha anche più funzionalità integrate per gestire i grafici, ovviamente - come il percorso più breve o gli attraversamenti profondi.
Un'altra importante differenza è che in un graphdb come neo4j è possibile attraversare il grafico in base a tipi e direzioni della relazione (bordo) senza caricare i nodi completi (comprese le proprietà/gli attributi del nodo). C'è anche la scelta di usare neo4j come backend di un oggetto db, pur essendo in grado di usare tutte le cose di graphy, vedi: jo4neo Questo progetto ha un approccio diverso che può anche contare come oggetto db su neo4j: neo4j.rb. Una nuova opzione è quella di utilizzare Spring Data Graph, che fornisce il supporto graphdb attraverso le annotazioni.
La stessa domanda è stata posta nei commenti a this blogpost.
Con i database di grafici, si ha una leggera parvenza di possibilità che si basi sulla teoria dei grafi matematici. Con i database orientati agli oggetti, si ha la certezza che non si basa affatto su nulla (e certamente nessuna teoria matematica).
Sì, l'API sembra la differenza principale, ma non è veramente superficiale. Concettualmente un insieme di oggetti formerà un grafico e potresti pensare a un'API che tratta questo grafico in modo uniforme. Al contrario, in teoria è possibile estrarre una struttura grafica generica per i pattern e mapparli agli oggetti esposti tramite alcune API. Ma la progettazione dell'API di un prodotto effettivo avrà generalmente conseguenze su come i dati vengono effettivamente archiviati, su come possono essere interrogati, quindi sarebbe tutt'altro che banale, ad esempio, creare un wrapper e farlo apparire come qualcos'altro. Inoltre, un database orientato agli oggetti deve offrire alcune garanzie di integrità e una struttura di battitura che un database grafico normalmente non eseguirà. In effetti, il database OO serio è lontano dalla "forma libera" :)
Dai un'occhiata a [HyperGraphDB] [1] - è sia un database completo orientato agli oggetti (come db4o) che un database grafico molto avanzato sia in termini di capacità di rappresentazione e di interrogazione. È in grado di memorizzare ipergrafi generalizzati (dove i bordi possono puntare a più di un nodo e anche ad altri bordi), ha un sistema di tipi completamente estensibile incorporato come grafico ecc.
A differenza di altri database di diagrammi, in HyperGraphDB ogni oggetto diventa un nodo o un bordo nel grafico, con intrusione API nulla-a-minima e hai la possibilità di rappresentare i tuoi oggetti come un grafico o trattarli in un modo che è ortogonale alla struttura del grafico (come "payload") valori dei tuoi nodi o bordi). Puoi fare attraversamenti sofisticati, indicizzazione e interrogazioni personalizzate.
Una spiegazione perché HyperGraphDB è in realtà un ODMS, vedere il post del blog È HyperGraphDB un database OO? sul sito Web di Kobrix.
La differenza a livello basso non è così grande. Entrambi gestiscono le relazioni come collegamenti diretti senza costosi join. Inoltre, entrambi hanno un modo di attraversare le relazioni con il linguaggio Query, ma il database grafico ha gli operatori per andare in modo ricorsivo all'n ° livello.
Ma la più grande differenza è nel dominio: in un database grafico tutto si basa sui 2 tipi: vertici e spigoli, anche se in genere è possibile definire i propri tipi come una sorta di sottotipi di Vertex o Edge.
Nell'ODBMS non ci sono concetti Vertex e Edge, a meno che non si scriva il proprio.