È una cattiva pratica generare id per un oggetto che non esiste ancora nel database?

Question

È una cattiva pratica generare id per un oggetto che non esiste ancora nel database?

#1 da (3 voti)
#2 da (0 voti)

4

Ecco la situazione:

C'è un database Mongo A e c'è il database Mongo B.

Esiste un concetto di business / un oggetto Mongo chiamato someModel che esiste su una delle raccolte del database B.

Ecco la domanda. Il modo in cui generiamo questo modello è basato sui dati di altri oggetti dal database A. E ci sono momenti in cui vogliamo caricare tutti i modelli esistenti (oggetti esistenti nel database B) e quelli non esistenti che sono solo un conglomerato di dati dalle raccolte del database A (come detto).

Ora per alcuni dei Modeli esistenti abbiamo un id Mongo che è unico ed è stato generato al momento della creazione, tuttavia per alcuni Moduli non esistenti non abbiamo ancora un ID. Il motivo per cui ne abbiamo bisogno è per scopi di identificazione / corrispondenza (tra front-end e back-end).

La linea di fondo è che sto pensando di generare un ID tramite Mongoose e avere un DTO completamente compilato in ogni momento, anche se l'ID sarà temporaneo (fino a quando non verrà salvato) e usato solo per scopi di identificazione / corrispondenza - tuttavia una volta salvato, l'"ID temporaneo" diventerà permanente.

L'ho intenzionalmente reso molto astratto in modo che sembri un problema generale invece di renderlo specifico per il business ma se voi ragazzi avete bisogno di maggiori dettagli, chiedete e ve li fornirò sicuramente.

Quindi questa è la domanda - se generare id per un oggetto non esistente nel database è una cattiva pratica in questo specifico contesto.

Grazie ragazzi e apprezzate il vostro tempo e supporto!

api-design api mongodb node.js mongoose

posta AvetisG 09.11.2016 - 17:49

fonte

2 risposte

0

In realtà non stai "generando id per un oggetto non esistente nel database [B]". Questo oggetto esiste.

@AvetisG, hai qualche entità di modello e alcuni attributi di entità di modello separati. La logica di applicazione è un maestro di alcune entità di modello, A e B sono entrambe un maestro di alcuni degli attributi di entità di modello. Nel tuo contesto è abbastanza valido avere un'entità someModel univoca (con il suo ID) in master (logica), ma non avere ancora i suoi attributi in A e / o B.

Non sono sicuro che abbia un significato nella tua situazione specifica, ma per me non sembra esserci alcuna ragione per mantenere l'ID (link a qualche entità di modello) in B e non tenerlo in A. Considera un'opzione per generare ID (creare alcune entità di modello) per tutti quei "conglomerati di dati" che sono assenti in B e memorizzarli. Renderebbe il ciclo di vita di qualche entità più ovvio in termini di dati sulla forma. Anche la gestione di archivi di impostazioni senza archiviazione di entità è una domanda.)

risposta data 09.11.2016 - 20:30

fonte

Leggi altre domande sui tag api-design api mongodb node.js mongoose

Perché utilizzare il numero di build al posto del versioning x.x.x in un'app Web è una cattiva idea? Come si dovrebbe modulare l'implementazione degli oggetti correlati?

score 3 · Accepted Answer

Come spesso dipende . Dal momento che hai chiesto una risposta generale, sto cercando di fornirne uno indipendente dalla tecnologia specifica, qui MongoDB.

Se l'intervallo di domini consentito per gli ID è enorme, e non stai permettendo al tuo database di generare diversi milioni di ID al secondo, quindi il rischio di esaurire gli ID disponibili in un ragionevole lasso di tempo è piccolo, allora puoi prendi quegli ID e usali per quello che vuoi (anche se questo significa che li usi solo temporaneamente e poi li butti via).

D'altro canto, quando le precondizioni di cui sopra non sono soddisfatte, devi stare attento a non arrivare a un punto in cui hai esaurito gli ID o ottieni conflitti di identità.

Ad esempio, l'utilizzo di GUID come ID (che utilizzano un intervallo di dominio di numeri a 128 bit) rende molto improbabile ottenere collisioni di ID purché non ne crei un'enorme quantità in un tempo breve, soprattutto quando è possibile limitare i test di collisione per il tuo caso di utilizzo speciale.

Fai anche attenzione che le gamme di domini che sembrano enormi oggi potrebbero non sembrare così enormi domani (il miglior esempio è il protocollo IP V4, dove gli indirizzi disponibili sono diventati scarsi nel corso degli anni).