indirizzo email come nome utente e campo indirizzo email

Come scritto, i tuoi requisiti sembrano chiari: c'è un campo separato per un nome utente e un campo separato per l'indirizzo e-mail.

Detto questo, potresti aver bisogno di discutere i requisiti con la persona che li ha scritti in primo luogo:

• Potrebbe sembrare che, tra le informazioni di contatto e i dati di autenticazione, sia necessaria una netta separazione. Ad esempio, potrebbero esserci più set di informazioni di contatto: uno per la fatturazione, un altro per la spedizione.

• Oppure potrebbe sembrare che dovrebbe essere lo stesso campo.

Due domande chiave sono:

• È possibile che la persona utilizzi un accesso che non è un indirizzo e-mail? Cosa succede se si tratta di un indirizzo e-mail diverso da quello specificato nelle informazioni di contatto?

• Cosa succede quando la persona ha bisogno di cambiare l'indirizzo e-mail, perché quello vecchio non è più valido? Cambierà anche il login?

Se i requisiti mi dicono di archiviare quelle che sembrano essere informazioni duplicate, la memorizzerei come tale nel mio oggetto e / o database.

Tuttavia, a meno che i requisiti non dicano anche che devo ritirare l'indirizzo email due volte (una volta come nome utente e separatamente come parte delle informazioni di contatto), chiederei all'utente una sola volta e copierò internamente le informazioni negli altri campi.

La ragione per implementare la duplicazione è perché ritengo probabile che la duplicazione apparente non sia una vera e propria duplicazione in tutti i casi. Forse è previsto un caso d'uso in cui il nome utente non è in realtà un indirizzo email valido, oppure è previsto un caso d'uso in cui un utente può modificare i propri dati di contatto (incluso l'indirizzo e-mail) senza cambiare il nome utente.

Se la duplicazione sembra essere molto seria per te, puoi sempre chiedere chiarimenti sul requisito.

In passato, il design che ho spinto quando avere il lusso di progettare questo da zero è di avere un'entità Person con una o più entità Utente. In questo modo puoi identificare persone uniche nel sistema e fornire la possibilità di più account utente che possono essere collegati a singole applicazioni o sistemi, se necessario.

Questo non tiene conto dell'uso di Active Directory o di un modello di Identity Federation, ma un semplice esempio del modello di oggetto potrebbe essere:

persona

• ID
• Nome
• Cognome
• Indirizzo email
• altre informazioni di contatto, ecc.

Account utente (le informazioni di accesso)

• ID
• ID utente FK
• ID applicazione FK
• Login (l'indirizzo email o l'ID utente)
• altri campi relativi all'accesso, ecc.

E puoi farlo ancora di più e avere più email per la persona scomposta in una tabella figlio, per email principale, secondaria, ecc. Lo stesso vale per telefono e indirizzo e altre informazioni simili che identificano una persona.

Progettando un modulo di accesso nel 2016 prenderemo in considerazione scenari senza password che sono ben ricompensati in questo question , oltre agli insegnamenti di base del data design: chiedi all'utente solo ciò che devi veramente chiedere .

Quindi per il tuo problema specifico resterei solo con una email - l'email dell'utente e non la chiamerei mai più che e-mail, non c'è un campo dati "username", che può solo confondere le cose (eventualmente puoi avvertire l'utente che spiega che l'email sarà usata come mezzo di autenticazione, ecc.) in definitiva, se i tuoi requisiti di sicurezza e sicurezza ti consentono di farlo, vai senza password