Sto costruendo un social network, che avrà caratteristiche standard di "Mi Piace" (upvotes) per i post, "seguito" tra utenti e "stelle" per i post preferiti. Questi potrebbero ragionevolmente espandersi in futuro per funzionalità simili.
Uso principalmente NoSQL (vale a dire, documenti MongoDB) ma apprezzerei anche una prospettiva SQL.
Ho intenzione di mantenerli in raccolte che potrebbero contenere documenti come segue:
Followers Collection, example doc: {follower_id: 123, followee_id: 456}
Likes Collection, example doc: {liker_id: 123, post_id: 789}
Stars Collection, example doc: {user_id: 123, starred_item_id: 555}
La struttura emergente sembra molto simile. Alcuni dati aggiuntivi potrebbero essere identici (data di creazione?), E mentre altri potrebbero essere diversi (tipo di elemento piaciuto / aggiunto / seguito e / o campi aggiuntivi specifici del tipo [diciamo un valore numerico per una classe 'valutazione']) sembra che ci sia così tanto in comune che potrebbe essere prudente consolidare tutti questi in un "modello" simile, sia in termini di una singola raccolta DB (o tabella SQL) che di modello di codice condiviso / singolo.
Sono principalmente preoccupato per:
- La raccolta è troppo grande - questa è già una preoccupazione solo per i "Mi piace", potrebbe essere esacerbata (anche se solo da ~ * 3) lanciando anche "stelle" e "follower".
- La logica tra questi oggetti di dati si allarga nel tempo, rendendo errato l'utilizzo di un modello di dati condiviso.
Quindi, sarebbe una buona idea? Mi piace / Stelle / Seguenti: sono più simili o più separati?
Più precisamente, assumendo 3 collezioni simili ma non identiche, avrebbe più senso consolidarle in una o tenerle separate? Entrambi considerano la complessità del codice (e DRYness) e i vincoli DB (ad esempio la dimensione dell'indice).