Modellazione dell'utente in MongoDB

0

Il nostro team sta imparando a lavorare con MongoDB. Dobbiamo modellare utente tra le altre cose per un'applicazione basata su OAuth. Sappiamo come modellare nel mondo relazionale, ma non siamo sicuri su come farlo in NoSQL.

Nella nostra applicazione identifichiamo l'utente in modo univoco dal suo indirizzo email . Gli indirizzi email sono naturalmente unici e anche verificabili. L'indirizzo email sembra essere un buon candidato per una chiave.

Non modelliamo la persona. Non abbiamo la possibilità di identificare una persona, solo il suo indirizzo email. Ciò significa che se una persona ha più di un indirizzo e-mail, avrà diversi documenti nel database. Inoltre, se cambia il suo indirizzo e-mail, usa un documento diverso. Inoltre, poiché le persone eseguono il login con OAuth, non esiste il concetto che gestiscano i loro dati. Non c'è password e il nome utente è dato da OAuth.

Perché non utilizzare l'indirizzo email per la chiave primaria di una raccolta _id ? In questo modo:

{
  _id: "[email protected]",
  name: "John Doe",
  provider: "example.com",
  comments: [
    // all comments
  ]
}

Quali sono i pro e i contro di questo approccio?

Modificato per chiarire la differenza tra persona e utente

    
posta nalply 04.07.2013 - 09:45
fonte

1 risposta

2

Questa risposta non è in alcun modo correlata a MongoDB, ma piuttosto all'applicabilità dell'utilizzo dell'email come chiave per i tuoi oggetti utente.

Se la tua applicazione è una sorta di applicazione basata su Internet dove gli utenti si registrano con il loro indirizzo email, allora è perfettamente possibile che un utente ottenga un nuovo indirizzo email nel tempo e gli utenti vorrebbero aggiornare l'indirizzo email registrato .

Questo porterà ad alcune sfide, se usi l'e-mail come chiave.

Dici di trattare una persona con diversi indirizzi email come diversi utenti. Ma c'è una differenza tra un utente che ha diversi indirizzi email e un utente che cambia la sua email principale in una nuova. Il blocco di una tale decisione progettuale limita le possibilità di modificare il sistema in modi nuovi in futuro. Almeno lo rende più difficile.

Se il sistema era una sorta di linea aziendale interna per un'azienda, la posta elettronica potrebbe non cambiare in quanto probabilmente sarebbe l'indirizzo di posta elettronica aziendale.

Ma come regola generale, sceglierei sempre la mia chiave come valore generato dal computer, e non un valore che ha un significato nel mondo reale (vedi chiave surrogata ).

    
risposta data 04.07.2013 - 09:57
fonte

Leggi altre domande sui tag