Esiste uno schema di progettazione accettato per la memorizzazione di alcune variabili globali in un database NoSQL?

Non ho familiarità con Mongoose, ma abbiamo iniziato a spingere la configurazione fuori dai file xml e nel DB usando ravendb. Il nostro approccio è:

• Creiamo un oggetto di configurazione o un grafico oggetto con valori predefiniti sensibili.
• Scriviamo una classe di Configuration Manager che fornisce:
  • creazione automatica dell'oggetto se non esiste
  • accesso singleton alla classe
  • gestisce la memorizzazione nella cache, ecc. se necessario

A livello di database è solo un documento speciale con un ID fisso - da qui il singleton. Abbiamo avuto alcuni approcci in cui abbiamo potuto scambiare varie configurazioni anche nel singleton "attivo". Dal punto di vista del codice, non è cambiato molto: abbiamo in genere iniettato la configurazione utilizzando i contenitori IoC, quindi il codice è stato abbastanza agnostico. Config è solo una manna dal cielo.

Nel complesso sono abbastanza soddisfatto. Il più grande svantaggio è che si configura il controllo della versione che è una caratteristica che mi è davvero piaciuta per l'aspetto dell'auditabilità.

Ho qualcosa di simile nella mia app. Se gli amministratori non sono troppi, ho un array aggiornatoUtenti [] in ogni documento evento che contiene i nomi delle persone che hanno visto l'evento. Se il nome dell'utente non è incluso, allora è nuovo per lui. Se hai intenzione di eseguire una query per la nuova, allora potrebbe essere necessario invertire questo (in modo da mantenere nonUpdatedUsers [] e query mongo per il nome utente in questo campo, indicizzati, naturalmente). mangusta o no è la tua scelta.

La seconda opzione è molto meglio.

Applicare una sorta di architettura ORM sarebbe fantastico.

Lo schema dell'utente dovrebbe probabilmente avere un campo aggiuntivo denominato account_type che verrà mappato allo schema dell'account che contiene l'elenco di tutti i tipi di utenti sulla tua applicazione. Oppure puoi avere un campo di stringa extra chiamato autorità, quindi per un utente normale avrà il ROLE_USER e probabilmente ROLE_ADMIN per l'utente amministratore.

Uno schema diverso dovrebbe contenere i dati degli eventi con un campo aggiuntivo in esso denominato status, che potrebbe contenere il valore "READ" o "UNREAD" a seconda di ciò che funziona per te.

Non ho familiarità con la mangusta in particolare, ma noto che il tuo primo suggerimento ha un problema interessante: se in seguito espandi il numero di utenti amministratori, avrai più copie dei dati che non sono necessariamente d'accordo tra loro , mentre sembra che per la tua applicazione vuoi veramente che i dati siano globali (dato che più utenti amministratori non dovrebbero avere tutti gli stessi eventi per rivedere). Questo punta strongmente alla tua seconda opzione.

Poiché non ho familiarità con la mangusta, non so se ci sia qualche ragione per parlare direttamente con mongodb sarebbe vantaggioso per te, ma se la seconda opzione è una possibilità, non vedo alcun motivo per cui dovrebbe essere necessario.