Senza JOINs, qual è il modo giusto per gestire i dati nei database di documenti?

Question

Capisco che i JOIN non sono né possibili né disapprovati nei database dei documenti. Vengo da una base di dati relazionale e sto cercando di capire come gestire tali scenari.

Supponiamo di disporre di una raccolta Dipendenti in cui memorizzo tutte le informazioni relative ai dipendenti. Quello che segue è un tipico dipendente documento:

{ 
    "id": 1234, 
    "firstName": "John", 
    "lastName": "Smith", 
    "gender": "Male", 
    "dateOfBirth": "3/21/1967", 
    "emailAddresses":[ 
     { "email": "johnsmith@mydomain.com", "isPrimary": "true" }, 
     { "email": "jsmith@someotherdomain.com", "isPrimary": "false" } 
    ] 
} 

Diciamo anche, ho una collezione progetti separati dove memorizzare i dati di progetto che sembra qualcosa di simile:

{ 
    "id": 444, 
    "projectName": "My Construction Project", 
    "projectType": "Construction", 
    "projectTeam":[ 
     { "_id": 2345, "position": "Engineer" }, 
     { "_id": 1234, "position": "Project Manager" } 
    ] 
} 

Se voglio restituire un elenco di tutti i miei progetti insieme ai team di progetto, come posso gestirmi assicurandomi di restituire tutte le informazioni pertinenti sui singoli membri del team, ovvero nomi completi, indirizzi e-mail, ecc.?

Si tratta di due query separate? Uno per i progetti e l'altro per le persone i cui ID sono presenti nella raccolta dei progetti?

In tal caso, come faccio quindi a inserire i dati relativi a persone, nomi completi, indirizzi e-mail? Faccio quindi un ciclo foreach nella mia app per aggiornare i dati?

Se mi affido alla mia applicazione per gestire l'inserimento di tutti i dati pertinenti, non si tratta di un calo di prestazioni che compenserebbe i vantaggi in termini di prestazioni dei database di documenti come MongoDB?

Grazie per il vostro aiuto.

Answer 1

"... come gestisco assicurandomi di restituire tutte le informazioni pertinenti sulle persone nel team, nomi completi, indirizzi e-mail, ecc. Sono due query separate?"

Si tratta di 2 query separate OPPURE denormalizzare nel documento di progetto. Nelle nostre applicazioni eseguiamo la seconda query e conserviamo i dati il ​​più possibile normalizzati nei documenti.

In realtà NON è comune vedere il tasto "_id" ovunque ma sul documento di livello superiore. Inoltre, per le raccolte in cui verranno inseriti milioni di documenti, si salva l'archiviazione mantenendo i tasti "concisi". Considera "nome" anziché "projectName", "type" piuttosto che "projectType", "pos" piuttosto che "position". Sembra banale ma si aggiunge. Dovrai anche inserire un indice su "team.empId" in modo che la query "su quanti progetti ha lavorato su Joe Average" funzioni correttamente.

{ 
    "_id": 444, 
    "name": "My Construction Project", 
    "type": "Construction", 
    "team":[ 
    { "empId": 2345, "pos": "Engineer" }, 
    { "empId": 1234, "pos": "Project Manager" } 
    ] 
} 

Un'altra cosa da abituarsi a è che non c'è bisogno di scrivere l'intero documento ogni volta che si desidera aggiornare un singolo campo o, diciamo, aggiungere un nuovo membro alla squadra. È possibile eseguire aggiornamenti mirati che identificano in modo univoco il documento, ma aggiornano solo un singolo campo o elemento di array.

db.projects.update(
    { _id : 444 }, 
    { $addToSet : "team" : { "empId": 666, "position": "Minion" } } 
); 

Le 2 domande per far sì che una cosa sia fatta male all'inizio, ma la supererai.

Answer 2

Mongo DB è un database di archiviazione di documenti. Supporta alta disponibilità e scalabilità.

Per restituire un elenco di tutti i progetti insieme al team di progetto (dettagli), in base alle mie considerazioni, sarà necessario eseguire 2 query. Dato che mongoDb non ha vincoli FK, dobbiamo mantenerlo a livello di programma. Invece dei vincoli FK, 1) se i dati sono inferiori, possiamo incorporare i dati come sottodocumento. 2) piuttosto che il modo normalizzato di progettare il db, in MongoDb dobbiamo progettare secondo il modello di accesso. cioè il modo in cui è necessario interrogare i dati più probabilmente. (Tuttavia il tempo per l'aggiornamento è più (lento), ma a livello utente la performance dipende principalmente dall'attività di lettura, che sarà migliore di RDBMS)

Il seguente link fornisce un corso di certificato su mongo Db, gratuito. Mongo DB University Hanno anche un forum, che è abbastanza buono.