Ho letto questa domanda più volte e, fondamentalmente, mi sembra che ci sia qualche incertezza sulla funzione di Tag s nel dominio. In un luogo, mostra:
Tag1: Personal -> develop -> Neo4j
Ecco come se Tag1 contenga un elenco ordinato di categorie.
Tuttavia, nel diagramma che segue immediatamente questa descrizione, sembra più come Tag s tenere una busta di Category s potenzialmente indipendente.
Poiché è abbastanza semplice organizzare Category s in vari modi l'uno rispetto all'altro, come la gerarchia tradizionale (come un organigramma), o altri tipi di gerarchia, non abbiamo necessariamente bisogno di Tag s per aiutare con quello.
Inoltre, possiamo assegnare un Note a più Category s, anche senza usare una nozione di Tag s.
Quindi, cosa vuoi offrire Tag s? Questa è una domanda da porre sul dominio; non si tratta di utilizzare database SQL vs. Neo4j rispetto a triple RFD .
Fare questa domanda sul dominio significa comprendere ciò che vedranno gli utenti; quali comportamenti / manipolazioni si aspettano disponibili . Ad esempio, per uno, sono veramente necessari / previsti Tag s? Per un altro, se aggiungiamo un Category a un Tag (o altrimenti aggiorniamo un Tag , ci aspettiamo che tutti Notes condividano quel Tag da aggiornare? (In altre parole, facciamo Tag s avere qualche identità, o sono solo valori?)
A seconda delle risposte alla domanda su cosa significhi Tag s nel dominio di interesse, possiamo modellarle in SQL usando la tabella o un database grafico usando nodi e relazioni. Non è affatto contrario ai database del grafico introdurre tante entità e relazioni necessarie per modellare adeguatamente il dominio.
Un vantaggio dei database di grafici è che possiamo memorizzare nuovi tipi di relazione senza la necessità di creare nuove tabelle relazionali e possiamo cercare tutte le relazioni senza nominare tabelle relazionali. Ciò significa che una query esistente potrebbe trovare risultati nelle relazioni che sono state appena aggiunte, cosa che non si verificherebbe in un database relazionale, poiché la query dovrebbe essere aggiornata per incorporare la nuova tabella. Tuttavia, dobbiamo rappresentare diversi tipi di informazioni utilizzando diversi nodi e relazioni; i database di grafici non rimuovono la necessità di avere tipi di entità e tipi di relazione diversi come richiesto dal dominio.
A volte, tuttavia, un database grafico (e come i tripli RDF) può essere limitato, e questo significa introdurre soluzioni un po 'artificiali.
Un esempio è rappresentato da (diversi) raccolte ordinate di (lo stesso), ad es. Categorie. Mantenere le varie raccolte ordinate separate l'una dall'altra è fondamentalmente un ottimo uso per le relazioni ternarie, che non sono supportate nei sistemi di modellazione che forniscono solo relazioni binarie.
Con Neo4j potremmo passare agli attributi del valore inserendo un numero di ordine nelle relazioni che raccolgono le Categorie (ad esempio in Tag ). (Se l'operando extra della relazione ternaria è un nodo anziché un valore, questo non funzionerà in Neo4j.) Questo (anche) non funzionerà in RDF poiché non possiamo attribuire relazioni con valori, e invece avremo per introdurre una tripla completamente nuova (relazione binaria).
In queste situazioni, in qualche modo dobbiamo carpire tutte le relazioni in relazioni binarie e ciò significa creare un'entità probabilmente in qualche modo innaturale per rappresentare operandi supplementari come un singolo elemento a cui può fare riferimento una relazione binaria. In questi casi, ci sono scelte un po 'arbitrarie su come farlo, proprio come i compilatori hanno una scelta multipla su come compilare costrutti di codice sorgente di alto livello in linguaggio assembly. Ad esempio, possiamo creare un'entità che rappresenti due degli operandi, quindi selezionarli come target in una relazione binaria. In alternativa, possiamo usare un approccio Davidsonian, che è quello di creare un'entità "statement", e verbi grammaticali (relazioni), come "Subject of" (non necessariamente da confondere con il tuo), "Object of", the " Paziente di ". Quindi possiamo creare più relazioni binarie individuali che descrivono l'intera affermazione e rappresentano la sua relazione più complessa. Un articolo sulla rappresentazione Davidsoniana di statermenti complessi
Questo è il motivo per cui considero i sistemi di modellazione che non hanno un ordine più alto o più alto come più analogo al linguaggio assembly, che richiede un metodo per tradurre relazioni più complesse che si verificano in natura. Buono per le macchine da manipolare ma non necessariamente appropriato per il consumo umano diretto.
Tuttavia, la maggior parte delle relazioni è binaria, quindi molte cose possono essere modellate in sistemi di relazioni solo binari senza queste complessità.
