7

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?

  • 3
    What are your requirements? – qwerty_so Dec 19 '16 at 12:56
  • I just updated the question to include requirements. Thanks – Lucas T Dec 19 '16 at 13:02
  • 2
    You might also have 2 different entities: account and user. May be it would help to see that conceptually, both fields are different thing and serves to different purpose. I'm not trying to complicate your design, I just want you see the two concepts separated. – Laiv Dec 19 '16 at 13:29
4

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?

  • Additionally, I'd ask whether the login email needs to be validated to confirm it is owned by the user. If so, the second email address may not be necessary as the system already has an email to contact the user with. – MetaFight Dec 19 '16 at 14:23
5

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.

  • 3
    +1. My Steam account username is still my old, now defunct, email address. Indeed I have updated the email, and the two no longer match. – Tibo Dec 19 '16 at 13:18
  • Your answer is as valid as the other one provided, I wish I could mark them both as correct. – Lucas T Dec 19 '16 at 14:17
2

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

  • ID
  • First Name
  • Last Name
  • Email Address
  • other contact info, etc.

User Account (the login info)

  • ID
  • Person ID FK
  • Application ID FK
  • Login (the email address or user ID)
  • other login-related fields, etc.

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.

  • I agree with you. Diving the information between person and account is the right approach. I shall give it due consideration. Thanks – Lucas T Dec 22 '16 at 10:43
2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.