Sto iniziando a pensare che molte mie tabelle potrebbero essere sostituite solo da un grafico db:
Ad esempio: Ho 4 tabelle: account, voti, post, relazioni
ma posso rappresentare tutto questo in una tabella di grafico con bordi diversi,
NODE1 -> type of relation -> NODE2 account -> vote_+1 -> post account -> wrote -> post account -> friend -> account2
c'è una differenza di prestazioni o altro tra di loro?
puoi sempre rappresentare i dati relazionali in forma di grafico
la chiave è come stai usando i dati - per lo più aggiornamenti transazionali, per lo più query di attraversamento grafico?
se hai tempo, esegui la conversione e profila le tue operazioni più comuni su entrambi i DB
In realtà, più che essere DB grafico, ciò che descrivi è più simile a triplestore .
Oggetto tripli - > predicato - > oggetto, è ciò che stai chiamando node1 - > type_of_relation - > node2.
Se lo abbini a motore di inferenza , puoi avere uno strumento molto potente. Saresti in grado non solo di interrogare le relazioni dirette, ma anche le relazioni implicite. Ad esempio, se definisci una regola come:
A - > nonno - > B: = (A - > parent - > x) & & (x - > parent - > B)
È possibile interrogare i nonni, ma non è necessario memorizzare tali informazioni nel DB. Ovviamente questo è un esempio molto semplice, puoi usarlo per costruire relazioni piuttosto complicate.
Il linguaggio di query per i triplestores è SPARQL , che è approssimativamente basato su SQL ed è abbastanza semplice da comprendere.
È un sistema live? Hai problemi di prestazioni?
Se no, non preoccuparti di cambiare tutto in un database grafico. Se non guadagni nulla, ma invece impieghi molto tempo lontano da altri compiti, ne vale la pena? No.
Se sì, identificare (profilo) se il problema è il database. In tal caso, eseguire alcuni test e verificare se un database grafico sarà più veloce.
Non solo "ottimizzare" senza realmente sapere se ne vale la pena. La cosa più importante è avere una buona architettura, e dopo puoi vedere se c'è un problema. Innanzitutto quando trovi il problema, inizi a trovare una soluzione migliore.
Una tabella di aiutanti di relazione di molti2many (una tabella con solo due chiavi esterne) è una lista di adiacenza digraph. Un grafico db può essere vantaggioso se hai molte relazioni m2m, ma ha lo stesso costo di un m2m, che è sempre una cosa negativa a meno che non siano veramente necessarie.
Ad esempio, account -> vote_+1 -> post e account -> friend -> account2 sono relazioni m2m, ma account -> wrote -> post non lo sono.
Assolutamente sì. GraphDB ti consente di velocizzare molte operazioni come l'attraversamento. Ma il guadagno dipende dal caso d'uso specifico.
Leggi altre domande sui tag database database-design