memorizzazione del dominio in più archivi

Question

memorizzazione del dominio in più archivi

#1 da (1 voti)

0

Sto sviluppando una sorta di gioco di ruolo basato sul web. Quindi per il mio dominio player ho trovato questo.

player oggetto avrà molti parametri come class , level , name e così via. Come oggetto piuttosto semplice, lo memorizzo nel database relazionale come PostgreSQL ad esempio. Ho un'entità RPlayer per quello.

Inoltre, volevo introdurre per player la possibilità di stabilire contatti con altri giocatori, alcune funzionalità di base dei social network. Per questo motivo ho deciso di utilizzare un database grafico come Neo4J . Ho un'entità GPlayer per quello. È un oggetto più semplice con alcuni campi univoci come id o name .

Come oggetto è diventato in qualche modo distribuito - tengo i dati per esso in diversi depositi - Ho aggiunto la mappatura di id in RDBMS a id in graphDB. Alla fine sembra così. (Non so come aggiungere campi in draw.io alla tabella, quindi qui ho solo tre campi e manca name ).

Nonhocollegatoplayersemappingtabellainquantounodeicampièesternoquindinonavevomotivodiconnettererelational_uuidaidinplayerstabella.

Quandohobisognodirecuperaretutto-uniscotuttiidatidaGPlayer-larappresentazionedelgiocatoreèilgrafico-eRPlayer-larappresentazionedelgiocatoreèlatabella-inCompletePlayeroggettochecontienetuttiicampidientrambiglioggetti.

Quando aggiungo un nuovo giocatore

1. I create record in app.players table and get r_ID
2. I create node in graphDB and get g_ID
3. I create record in util.mapping for r_ID and g_ID

Anche i 3 passaggi che sto pianificando di fare nell'ambito di global transaction .

Questo approccio è ok? Dovrei in qualche modo memorizzare il dominio nel singolo database e non diffonderlo tra diversi archivi?

architecture

posta lapots 28.11.2017 - 13:48

fonte

1 risposta

Leggi altre domande sui tag architecture

Iniezione del metodo del costruttore, è questo uno schema? java.util.function.Function come interfaccia per un oggetto mutabile

score 1 · Accepted Answer

In linea di principio, non hai torto (supponendo che hai davvero bisogno di database separati). Alcuni possibili miglioramenti:

A meno che tu non abbia una ragione specifica, probabilmente non dovresti memorizzare il nome del giocatore nel database grafico, solo gli ID e le relazioni tra i giocatori.
Se ogni giocatore sarà associato esattamente a una voce in ogni database, non è necessario disporre di una tabella di mappatura. Usa lo stesso ID per entrambi. Se non è possibile utilizzare lo stesso Id in entrambi i database (per qualche motivo), memorizzare l'ID creato in un database come un campo nei record dell'altro database: ad es. memorizza g_Id come parte di un record del giocatore.
Potrebbe avere senso non unire le informazioni in un singolo oggetto, ma piuttosto recuperare solo l'oggetto giocatore e poi avere un ComradesService o qualcosa che puoi usare per ottenere informazioni sulle relazioni.

Soprattutto l'ultimo punto dipende molto da quello che stai usando realmente per il DB grafico. Tuttavia, se le informazioni che si recuperano sono ragionevolmente complesse, caricarle ogni volta potrebbe non essere saggio. Se è semplice (ad esempio, chi è un compagno di chi?), Allora potrebbe essere meglio eliminare completamente il DB grafico.

Infine, se devi fare query di grafi complessi, ma hai anche una funzione semplice come quella sopra menzionata, potresti replicare le semplici informazioni nel DB relazionale.