Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm designing an entity to represent a log-in object. The unique username value is an email address, that will go onto the username field.
Should I add a second field called email to indicate a contact email address for the user considering that it would be valued copied from the username field?
My requirements are email address as username, password, plus contact details such as first name, last name, email address.
When you came across a scenario like this, what did you choose to do?
As written, your requirements seem clear: there is a separate field for a user name, and a separate field for the e-mail address.
This being said, you may need to discuss the requirements with the person who have written them in the first place:
It may appear that, indeed, there is a clear separation required between the contact info and the authentication data. For instance, there may be multiple contact info sets: one for invoicing, another one for shipping.
Or it may appear that it should be the same field.
Two key questions are:
Is it possible for the person to use a login which is not an e-mail address? What if it's a different e-mail address from the one specified in the contact info?
What happens when the person needs to change the e-mail address, because the old one is no longer valid? Will the login change as well?
If the requirements tell me to store what appears to be duplicate information, then I would store it as such in my object and/or database.
However, unless the requirements also say that I must collect the email address twice (once as user name and separately as part of the contact information), I would ask the user only once and internally copy the information to the other fields.
The reason for implementing the duplication is because I consider it likely that the apparent duplication turns out to not be an actual duplication in all cases. Perhaps a use-case is foreseen where the user name is not actually a valid email address, or a use-case is foreseen where a user can change their contact details (including email address) without changing the username.
If the duplication appears to be really serious to you, then you can always ask for clarification on the requirement.
In the past, the design I have pushed for when having the luxury of designing this from scratch is to have a Person entity having one or more User entities. This way you can identify unique people in the system and provide the ability for multiple user accounts that can be tied to individual applications or systems, if that's needed.
This doesn't take into account using Active Directory or some Identity Federation model, but a simple example of the object model could be:
Person
User Account (the login info)
And you can take it even further and have multiple emails for the person broken out into a child table, for primary email, secondary, etc. Same goes for phone and address and other similar information identifying a person.
Designing a login form in 2016 I would take into consideration passwordless scenarios which are well recapped in this question, plus the basic teachings of data design: ask the user only what you really need to ask.
So for your specific problem I'd stay only with an email - the user email and I would never call it anything else than email, there is no "username" data field, that can only confuse things (eventually you could alert the user explaining that the email will be used as an authentication mean, etc.) ultimately, if your security and safety requirements allow you to do so, go passwordless
