Quando utilizzare un database nosql come mongodb su mysql?

Sono nuovo nel concetto di database nosql e non l'ho mai usato. Sulla base di ciò che ho letto e del poco che ho capito, non vedo ancora come possano essere particolarmente utili se non puoi fare riferimenti tra i dati, se non esiste un concetto di chiave esterna.

Come potrei ad esempio interrogare qualcosa di semplice come "trova tutti i commenti pubblicati da questo utente", "trova tutte le foto che appartengono a un'entità album" ecc.

I sistemi nosql si allontanano dal modello di dati relazionale statico ma consentono comunque di tenere traccia di tali riferimenti, esiste qualcosa di analogo alle chiavi esterne che è possibile utilizzare nelle query?

Usi generali

• Se si dispone di strutture di dati che non sono chiaramente definite al momento della creazione del sistema. Tendo a mantenere le impostazioni dell'utente in nosql, per esempio. Un altro esempio era un sistema in cui gli utenti dovevano essere in grado di aggiungere campi in fase di esecuzione - molto doloroso in un RDBMS e un gioco da ragazzi in NoSQL.

• Se la struttura del modello è in gran parte centrata su uno o pochi oggetti modello e la maggior parte delle relazioni sono in realtà oggetti figlio degli oggetti modello principali. In questo caso scoprirai che avrai abbastanza poco bisogno di effettivi join. Ho scoperto che il sistema di gestione dei contatti può essere implementato abbastanza bene in nosql per esempio. Una persona può avere più indirizzi, telefoni ed e-mail. Invece di metterli ciascuno in una tabella separata, diventano tutti parte dello stesso modello e hai un oggetto persona.

• Se si desidera trarre vantaggio dal raggruppamento dei dati su più server anziché disporre di un server monolitico, che è comunemente richiesto da RDBMS.

• Caching. Anche se si desidera utilizzare un RDBMS come database principale, può essere utile utilizzare un database NoSQL per memorizzare nella cache i risultati delle query o conservare i dati, ad esempio i contatori.

• Archiviazione di documenti. Se si desidera archiviare documenti coerenti, in un database alcuni dei database NoSQL (come MongoDB) sono in realtà specializzati nella memorizzazione di questi.

E i join?

Onestamente, la cosa no join sembrava abbastanza spaventosa anche per me all'inizio. Ma il trucco è smettere di pensare in SQL. Devi effettivamente pensare con l'oggetto che hai in memoria quando esegui la tua applicazione. Questi dovrebbero più o meno essere salvati nel database NoSQL mentre si trovano nell'area.

Poiché è possibile memorizzare il grafico completo degli oggetti, con oggetti figlio, la maggior parte della necessità di join viene eliminata. E se trovi di averne bisogno, dovrai mordere il proiettile, recuperare entrambi gli oggetti e unirti al codice dell'applicazione.

Fortunatamente, la maggior parte dei driver può fare il join per te, se hai impostato lo schema nel modo giusto.

Per ulteriori letture, in realtà raccomando Martin Fowler .

Utilizzerei sicuramente un tale database durante le fasi di pianificazione di un progetto (prima dello sviluppo, prima ancora della progettazione) per registrare dati la cui struttura, relazioni e caratteristiche non sono ancora conosciute e soggette ad analisi. Dopodiché proverei a fare in modo che tutto si adatti a un modello relazionale.

In alcuni casi, non avrai bisogno di chiavi esterne. Per esempio:

Trova tutti i commenti pubblicati da questo utente

può essere semplice come caricare la commentsparte di un documento corrispondente a un utente. Questo si chiama denormalizzazione : invece di avere due set con un join, hai un documento e tutto il necessario è all'interno del documento. Una query, nessun join, prestazioni migliori .

Ma in alcune circostanze, ciò può comportare la duplicazione dei dati , quindi il collegamento da un documento all'altro potrebbe essere adatto. In questo caso, si può essere interessati da MongoDB normalizzazione, chiave esterna e unendo , Riferimenti database di pagina e in particolare caratteristica DBRefs.