base NoSQL disegno documento domanda

Question

Sto cercando di capire come implementare al meglio questo per il mio sistema ... e ottenere la testa fuori dallo spazio RDBMS per ora ...

Una parte del mio attuale DB ha tre tabelle: Show, ShowEntry e Entry. Fondamentalmente ShowEntry è una tabella di unione molti-a-molti tra Show e Entry. Nel mio RDBMS è logico pensare che qualsiasi modifica a Mostra dettagli può essere eseguita in un unico posto, e lo stesso vale per Voce.

Qual è il modo migliore per riflettere questo in uno spazio di archiviazione basato su documenti? Sono sicuro che non esiste un modo per farlo, ma non posso fare a meno di pensare se lo storage basato su documenti sia appropriato per questo caso.

Per la cronaca, sto valutando la possibilità di implementare RavenDB. Mentre le discussioni sul design NoSQL generale saranno buone, più uno focalizzato su RavenDB sarà fantastico!

Grazie, D.

Answer 1

Quando si modella una relazione molti-a-molti in un database di documenti, di solito si archivia una raccolta di chiavi esterne in uno solo dei documenti. Il documento che scegli in gran parte dipende dalla direzione in cui intendi attraversare la relazione. Attraversarlo da una parte è banale, attraversarlo nella direzione opposta richiede un indice.

Prendere l'esempio del carrello. È più importante sapere con esattezza quali oggetti si trovano in un cesto particolare rispetto a cui i cesti contengono un particolare oggetto. Dato che di solito seguiamo la relazione nella direzione da carrello a articolo, è più logico memorizzare gli ID oggetto in un carrello piuttosto che archiviare gli ID carrello in un articolo.

È ancora possibile attraversare la relazione nella direzione opposta (ad esempio cercare i cestini contenenti un particolare oggetto) utilizzando un indice, ma l'indice verrà aggiornato in background in modo che non sia sempre accurato al 100%. (È possibile attendere che l'indice diventi accurato con WaitForNonStaleResults, ma tale ritardo verrà visualizzato nell'interfaccia utente.)

Se si richiede un'accuratezza immediata del 100% in entrambe le direzioni, è possibile memorizzare chiavi esterne in entrambi i documenti, ma l'applicazione dovrà aggiornare due documenti ogni volta che una relazione viene creata o distrutta.

Answer 2

This è andato un lungo cammino verso la soluzione la mia domanda!