Sfondo
Per iniziare, al lavoro lavoro con un sistema legacy che, ai suoi tempi, era piuttosto spettacolare, ma ora è ... interessante ... con cui lavorare. Usa IBM (ora Rocket) UniVerse come database di supporto. Una parte in particolare che ha causato alcuni problemi è la mancanza di controlli sull'integrità dei dati. Per integrità dei dati, non intendo corruzione dei file, ma piuttosto cose come record orfani o chiavi non valide. La versione particolare che usano non supporta cose come i trigger e così via, a meno che il programmatore non si sia ricordato di aggiornare i propri indici calcolati, diventa "rotto" e pieno di dati errati. Ora, gli altri programmi sono stati creati per vivere con questi dati errati, ma è più fastidioso quando lo si inserisce in un altro database, come MySQL (utilizzando InnoDB come motore) che ha effettivamente dei vincoli sui dati.
La domanda
Sto sperimentando con MongoDB e NodeJS solo per vedere di cosa si tratta. Mi piace molto anche Mongoose e il suo sistema di schemi. Ho letto molto su cosa memorizzare su ogni disco in una raccolta separata. Forse è solo un mio pregiudizio RDBMS, ma ho deciso di memorizzare ogni "tipo" di cosa in una raccolta separata e utilizzare la funzionalità "popolare" di Mongoose per collegare essenzialmente i record. Ora, sono sicuro che qualcuno dirà che va contro l'intera cosa di NoSQL, ma non ho letto da nessuna parte che dice che solo perché qualcosa memorizza i documenti invece dei record e non ha uno schema impostato sul livello db che sia non può essere reso relazionale.
Nel mio esperimento, ho "Post" e "Commenti". Vedo quattro modi per memorizzare la relazione tra questi due:
- I dati completi per ogni commento vengono inseriti direttamente nel post sotto forma di documento secondario. Ci sono due svantaggi principali che ho visto con questo: se decido di mettere commenti su qualcos'altro (diciamo una "pagina"), devo essenzialmente ripetermi e non è così semplice scoprire come molti commenti che un utente ha pubblicato se i commenti sono effettivamente memorizzati in varie raccolte
- I commenti sono una raccolta separata e memorizzano la chiave del genitore e un nome dello schema per mangusta da utilizzare durante il popolamento (il cambio del nome dello schema non sarebbe automatico). Questo non è male, ma è orientato verso il caricamento dei commenti prima e post più tardi. Trovare i commenti su un post non è difficile, ma richiede una query manuale.
- I commenti sono una raccolta separata e i post hanno un elenco di ID di commento che si riferiscono a loro. Questo è prevenuto per prima cosa nel caricare i post e scoprire che cosa è associato a un commento diventa difficile. Tuttavia, la mangusta mi consente di caricare i commenti senza dover scrivere nulla di aggiuntivo.
- I commenti sono una raccolta separata e hanno un ID genitore. I post contengono anche un elenco di ID commenti. Questo combina i due metodi precedenti e neutralizza i loro contro e fa relativamente poche query "manuali", ma introduce la possibilità che i dati diventino sporchi e non sincronizzati come il sistema legacy che ho descritto sopra (ad esempio un commento dice che appartiene a un post e un altro post (o più post) afferma di essere il proprietario di quel commento).
Stavo seguendo l'ultimo percorso sopra elencato e mi sono reso conto che stavo iniziando a entrare nel regno di questo sistema legacy che aveva causato così tanti mal di testa con i suoi indici aggiornati manualmente e la possibilità di dati errati.
Ora, non mi aspetto di fare un sacco con questo mio piccolo esperimento, ma è il principale della cosa che mi fa pensare. Cosa consiglieresti di seguire su questo? Voglio essere in grado di mantenere bassi i conteggi delle query, ma non voglio nemmeno dover ricordare di aggiornare tutti questi indici. Deve esserci un mezzo felice da qualche parte.
Un'altra opzione, ovviamente, è utilizzare MySQL con alcuni vincoli di schema, ma non è questo il punto di questo particolare esercizio, visto che l'ho già fatto un sacco di volte.