Sfondo
Sto lavorando a un progetto che richiede di tenere traccia delle transazioni e del flusso di elementi in un gioco. Per fare ciò, sto memorizzando quelle transazioni in un grafico db (Orient-DB).
Un Negozio nel gioco può avere zero o più basekts ognuno dei quali può contenere un tipo di oggetto. Quindi, quando un giocatore vende qualcosa, gli oggetti venduti (se presenti) verranno messi nel rispettivo paniere e la transazione sarà completata.
Domanda
Non sono del tutto sicuro di come modellare quel comportamento correttamente però. Posso pensare a due modi più o meno sensati per rappresentarlo, ma non so quale sia la rappresentazione migliore per questo scenario.
Cose che ho bisogno di sapere in qualsiasi momento
- come è finito l'articolo x nel carrello y
- di quale transazione era responsabile?
- quale giocatore ha venduto quell'oggetto?
- quali negozi / giocatori hanno fatto passare l'articolo x in precedenza
- quale giocatore ha fatto affari con il negozio x (e il retro)?
Opzione A:
Creounverticedellatransazioneecreospigolitraquesto,tuttietuttiItems
,Basket
ePlayer
inquestione.Ilrovesciodellamedagliaèchedevoaggiungeredatiaibordidicontains
,perspecificarequaleelementoèandatoincuiBasket
(quiinazzurro).
OpzioneB:
Aggiungo ulteriori nodi, per collegare le transazioni con Baskets
e Items
.
Qui posso rappresentare tutti i dati nel grafico sotto forma di vertici e spigoli ma sto introducendo ancora più hop per ottenere da Shop
a Player
.
Lo svantaggio di A che potrebbe vedere è che quando voglio ottenere gli elementi di una determinata transazione, devo fare ulteriori query se voglio sapere come un Item
è finito in quello specifico Basket
.
Da che parte dovrei andare? C'è un'opzione migliore?
Sarebbe vantaggioso aggiungere un vantaggio diretto tra Player e Shop (con riferimento alla transazione come proprietà) per ridurre il luppolo non necessario quando tutto ciò che voglio sapere è, chi è andato in un negozio?
Penso che questa domanda si riduce a, quanti vertici sono troppi e quando li separo in diverse query (fondamentalmente come un JOIN
nei database relazionali)?
Ho preso in considerazione un log delle transazioni per questo, ma alcuni requisiti che devono essere interrogati renderebbero questo un inferno a JOIN