È una buona idea non incorporare certe relazioni uno a uno in un database Mongo?

Question

È una buona idea non incorporare certe relazioni uno a uno in un database Mongo?

#1 da (3 voti)
#2 da (1 voti)

4

Sto progettando uno schema di database NoSQL - MongoDB in particolare - e mi chiedo se sia una buona idea non incorporare certe relazioni one-to-one.

Per un esempio, ho una raccolta accounts , che memorizza tutte le informazioni sull'account. Il saldo dell'account richiede alcuni calcoli da calcolare e vedo due opzioni:

Avere un campo cached_balance nella raccolta accounts , che inizia come null. Ogni volta che il saldo viene ricalcolato, il campo per l'account in questione viene aggiornato.
Avere una raccolta account_balances_cache con una relazione uno a uno con accounts . Ogni volta che il saldo viene ricalcolato, il campo pertinente in questa raccolta viene aggiornato.

Il vantaggio del documento incorporato è che ottengo tutte le informazioni in un join. Una raccolta separata richiederebbe un join a livello di applicazione che non è così maneggevole.

Tuttavia, la ragione per cui ho pensato di avere una collezione separata è perché mi piace la sua separazione concettuale. C'è una raccolta per tutti i dati importanti che non devono essere persi, e ce n'è un'altra con dati che potrebbero essere ricalcolati in qualsiasi momento, dove l'intera collezione potrebbe essere eliminata e nulla del valore finale sarà stato perso. O potrebbe anche essere in un altro database che potrebbe essere tenuto su un server diverso, ecc. Questo è un ragionamento del suono o lo sto rendendo inutilmente difficile per me stesso?

(Si noti che questo è un esempio semplificato. In realtà le cose in queste cache possono essere difficili da computare a livello di calcolo, motivo per cui le inserisco nel database invece di qualcosa di simile a redis o memcached.)

language-agnostic database-design mongodb

posta Claudiu 16.03.2016 - 06:32

fonte

2 risposte

Leggi altre domande sui tag language-agnostic database-design mongodb

Qual è lo schema migliore per definire il proprio tipo con la raccolta definitiva di valori? Lingua Ubiquitous e livello di maturità nell'API REST?

score 3 · Answer 1

Specificamente, se stai usando MongoDB, allora nella mia vista dovresti davvero archiviare il valore memorizzato nella raccolta account nel documento, e non in una raccolta separata. Il motivo è che MongoDB garantisce solo l'atomicità sulle scritture su base documentale. Quindi non avresti modo di evitare che i potenziali valori memorizzati nella cache non siano sincronizzati con il saldo dell'account effettivo se lo diffondi su due raccolte.

score 1 · Answer 2

L'opzione 1 ha senso perché questo è il margine che si ottiene dagli archivi di documenti / valori-chiave. C'è comunque un suggerimento:

Invece di crearlo con un valore null, crealo in movimento come on quando richiesto.
aggiungi / aggiorna il rispettivo campo nel documento che detiene internamente il documento comprende diversi campi che hai intenzione di creare in account_balance_cache.
Puoi filtrare sulla raccolta di account per recuperare i saldi in base all'account ecc.
Per il calcolo costoso non vedo alcun problema perché cache_balance è un documento all'interno della creazione di un account che contiene diversi account come documento.

La raccolta di account di esempio rappresenta il documento dell'account:

[{
    accid:x, 
    name:y, 
    cache_balance:[{ #fields for balances}] 
}, 
{}]

Nell'opzione 2, stai andando verso la normalizzazione, e se si tratta di una normalizzazione, allora perché document store?