I dati delle sub-risorse dovrebbero essere incorporati nell'entità risorsa o duplicati nel documento NoSQL?

Question

I dati delle sub-risorse dovrebbero essere incorporati nell'entità risorsa o duplicati nel documento NoSQL?

#1 da (1 voti)

2

Ho uno scenario simile a come illustrato di seguito,

public class Post {
    private int id;
    private int postType;
    private int score;
    private User originalPoster;
    private String title;
    private String body;
    private String tags;

}

public class Comment {
    private int id;
    private int postId;
    private String text;
    private int score;
    private User userId;
}

public class User {
    int id;
    String displayName;
    int score;
}

Come modellare il mio oggetto documento / dominio MongoDb?

Le mie opzioni iniziali sono,

1) Avere raccolte di post e commenti separate e gestire aggiornamenti / retrieval si nascondono dietro la mia risorsa di riposo con possibile duplicato di commenti in post e commenti.

2) Hai un singolo post del documento e includi tutto in esso e hai solo una risorsa di riposo? Ciò limiterà i miei modelli di URL o la necessità di complessi dati recuperati alla fine di MongoDB.

Se dovrei andare con 1) o 2) o c'è un altro approccio in cui posso avere la flessibilità dei programmatori e minimizzare le interazioni NoSQL?

rest nosql mongodb

posta TheWhiteRabbit 21.02.2013 - 10:17

fonte

1 risposta

Leggi altre domande sui tag rest nosql mongodb

Memorizzazione di dati "sensibili" nel file delle impostazioni Gestione del messaggio di errore per un modulo di login di Spring MVC

score 1 · Answer 1

Prefaggerò questo con un disclaimer - Ho zero tempi di postazione in MongoDb. Ho una buona dose di tempo di seduta in altri database di documenti e penso che questi problemi siano simili. Ma potrebbero esserci alcune cose specifiche di mongo che potrei mancare qui - non ho idea di cosa siano i modelli di url o di come li userebbero.

Con i database di documenti, in generale l'approccio migliore sarebbe quello di pensare ai limiti della transazione qui - che dovrebbe essere il modo in cui si definisce ciò che è in un determinato documento. Ad esempio, hai sempre a che fare con post e commenti o, a volte, solo post? Hai degli angoli in cui devi trattare i commenti a livello individuale?

Un altro problema sono le preoccupazioni pratiche, come nel caso in cui si disponga di un post caldo con 15.000 commenti. Anche con 1kb / commento stai osservando alcuni tempi di caricamento abbastanza brutti se vuoi solo mostrare quel post.

In ogni caso, probabilmente farei un post a tutto e aggiungere un campo per "parentPostId" o qualcosa del genere. Quindi modificherei PostsWithComments come un indice piuttosto che un documento concreto che dovrebbe darti il meglio di entrambi i mondi: è facile ottenere dati post completi mantenendo al tempo stesso scritture e altri problemi di manutenzione. Gli indici sono i tuoi migliori amici qui.