我应该使用数字或电子邮件ID来识别网站上的用户吗?

时间:2023-02-07 07:12:06

I have a web app where I register users based on their email id.

我有一个网络应用程序,我根据他们的电子邮件ID注册用户。

From a design/ease of use/flexibility point of view, should I assign a unique number to each user or identify user based on emailid?

从设计/易用性/灵活性的角度来看,我应该为每个用户分配一个唯一的号码还是根据emailid识别用户?

Advantage of assigning unique number:

分配唯一号码的优点:

  1. I can change the login itself at a later point without losing the data of the user(flexible).
  2. 我可以在以后更改登录本身而不会丢失用户的数据(灵活)。

Disadvantage:

  1. I have to deal with numbers when using the sql command line(error prone).
  2. 使用sql命令行时我必须处理数字(容易出错)。

Which is better? Do you see any other issues that need to be considered for either scheme?

哪个更好?您是否看到任何一个方案需要考虑的其他问题?

7 个解决方案

#1


9  

The identity of your users should be unique and immutable. Choosing the email address as identity is not a good idea for several reasons:

用户的身份应该是唯一且不可变的。选择电子邮件地址作为身份不是一个好主意,原因如下:

  • The email is one facet of the user's identity that can change at any point in time.
  • 电子邮件是用户身份的一个方面,可以随时更改。

  • You might decide to allow more than one emails.
  • 您可能决定允许多个电子邮件。

  • You might decide to add other facets, like OpenID or Live ID, or even just old plain username.
  • 您可能决定添加其他方面,例如OpenID或Live ID,甚至只是添加旧的普通用户名。

  • There's nothing wrong with allowing multiple identityies to share the same email facet. It is a rare scenario, but not unheard of.
  • 允许多个身份共享同一个电子邮件方面没有任何问题。这是一种罕见的情况,但并非闻所未闻。

  • Normalizing the email address is hard and error prone, so you might have problems enforcing the uniqueness. (Are email addresses case sensitive? Do you ignore . or + inside emails? How do you compare non-english emails?)
  • 规范化电子邮件地址很难并且容易出错,因此您可能在执行唯一性时遇到问题。 (电子邮件地址是否区分大小写?您是否忽略。或+内部电子邮件?您如何比较非英语电子邮件?)

Btw, using the email as a public representation of the user identity can be a security and privacy problem. Especially if some of your users are under 13 years. You will need a different public facet for the user identity.

顺便说一句,使用电子邮件作为用户身份的公开表示可能是安全和隐私问题。特别是如果您的一些用户不满13岁。您将需要一个不同的公共方面来表示用户身份。

#2


6  

Use both. You have to add an id because you really don't want other tables to use the email address as a foreign key. Make the email address unique so that you can still use it to identify a user with sql command line.

两者兼用。您必须添加一个id,因为您确实不希望其他表将该电子邮件地址用作外键。使电子邮件地址唯一,以便您仍然可以使用它来识别具有sql命令行的用户。

#3


2  

Unique number - ALWAYS! But keep the number hidden from the user.

独一无二的号码 - 总是!但请保持用户隐藏号码。

The user should be allowed to change their email. If this is used as the primary identifier then it can cause lots of complications when the key is used in multiple tables.

应允许用户更改其电子邮件。如果将其用作主要标识符,则在多个表中使用密钥时会导致许多复杂情况。

#4


1  

You should have another identifier other then the users email address which is not visible to the user and never changes. You should then enforce uniqueness on the email address so it can be used as a candidate key.

除了用户不可见的用户电子邮件地址之外,您应该有另一个标识符,并且永远不会更改。然后,您应该在电子邮件地址上强制执行唯一性,以便将其用作候选键。

You will find that users will want to change their email address, or anything really which they can see, so you should as good practice have an identifier which cannot be changed.

您会发现用户希望更改他们的电子邮件地址,或者他们可以看到的任何内容,因此您应该尽可能地使用无法更改的标识符。

Dealing with numbers in sql command object would not really be any more error prone then using the actual email address, if anything I would think it would be less error prone.

在sql命令对象中处理数字实际上不会更容易出错,然后使用实际的电子邮件地址,如果有什么我会认为它不会出错。

#5


1  

Your disadvantage is not a disadvantage. Using numbers with sql is not more or less a problem than using emails or anything else for the matter.

你的缺点不是缺点。与使用电子邮件或任何其他内容相比,使用带有sql的数字并不是一个问题。

On the other hand your advantage is quite a strong one, you might want to associate users with each other, different emails with one user account, etc. and always using the email will make things harder.

另一方面,您的优势非常强大,您可能希望将用户彼此关联,使用一个用户帐户关联不同的电子邮件等,并且始终使用电子邮件会使事情变得更难。

Think also of urls including user identication, an ID is much easier to handle there than an email where you have to think about the proper url endocing.

还要考虑包括用户身份验证在内的网址,ID比在电子邮件中更容易处理,您需要考虑正确的网址拦截。

So in favour of flexiblity and ease of use, I would strongly recommend a unique userID.

因此,为了支持灵活性和易用性,我强烈建议使用唯一的用户ID。

#6


0  

Just some points to consider.

只需要考虑一些要点。

  • How will you validate the email address?
  • 您将如何验证电子邮件地址?

  • How do you ensure that it is really unique (I don't always use my real address e.g. m.mouse at disney.com
  • 你如何确保它真的是独一无二的(我并不总是使用我的真实地址,例如在disney.com上的m.mouse

  • I like to use a unique key generated by the database to identify the record and then add attributes which are out of my control separately
  • 我喜欢使用数据库生成的唯一键来标识记录,然后单独添加不受我控制的属性

  • A person's email can change but the id will not
  • 一个人的电子邮件可以更改,但ID不会

#7


0  

Unique numbers. As well as the reasons identified, I think it would be less error prone than using an email address. Shorter, no funny characters, easier to validate, etc.

唯一的数字。除了确定的原因之外,我认为它比使用电子邮件地址更不容易出错。更短,没有搞笑角色,更容易验证等。

#1


9  

The identity of your users should be unique and immutable. Choosing the email address as identity is not a good idea for several reasons:

用户的身份应该是唯一且不可变的。选择电子邮件地址作为身份不是一个好主意,原因如下:

  • The email is one facet of the user's identity that can change at any point in time.
  • 电子邮件是用户身份的一个方面,可以随时更改。

  • You might decide to allow more than one emails.
  • 您可能决定允许多个电子邮件。

  • You might decide to add other facets, like OpenID or Live ID, or even just old plain username.
  • 您可能决定添加其他方面,例如OpenID或Live ID,甚至只是添加旧的普通用户名。

  • There's nothing wrong with allowing multiple identityies to share the same email facet. It is a rare scenario, but not unheard of.
  • 允许多个身份共享同一个电子邮件方面没有任何问题。这是一种罕见的情况,但并非闻所未闻。

  • Normalizing the email address is hard and error prone, so you might have problems enforcing the uniqueness. (Are email addresses case sensitive? Do you ignore . or + inside emails? How do you compare non-english emails?)
  • 规范化电子邮件地址很难并且容易出错,因此您可能在执行唯一性时遇到问题。 (电子邮件地址是否区分大小写?您是否忽略。或+内部电子邮件?您如何比较非英语电子邮件?)

Btw, using the email as a public representation of the user identity can be a security and privacy problem. Especially if some of your users are under 13 years. You will need a different public facet for the user identity.

顺便说一句,使用电子邮件作为用户身份的公开表示可能是安全和隐私问题。特别是如果您的一些用户不满13岁。您将需要一个不同的公共方面来表示用户身份。

#2


6  

Use both. You have to add an id because you really don't want other tables to use the email address as a foreign key. Make the email address unique so that you can still use it to identify a user with sql command line.

两者兼用。您必须添加一个id,因为您确实不希望其他表将该电子邮件地址用作外键。使电子邮件地址唯一,以便您仍然可以使用它来识别具有sql命令行的用户。

#3


2  

Unique number - ALWAYS! But keep the number hidden from the user.

独一无二的号码 - 总是!但请保持用户隐藏号码。

The user should be allowed to change their email. If this is used as the primary identifier then it can cause lots of complications when the key is used in multiple tables.

应允许用户更改其电子邮件。如果将其用作主要标识符,则在多个表中使用密钥时会导致许多复杂情况。

#4


1  

You should have another identifier other then the users email address which is not visible to the user and never changes. You should then enforce uniqueness on the email address so it can be used as a candidate key.

除了用户不可见的用户电子邮件地址之外,您应该有另一个标识符,并且永远不会更改。然后,您应该在电子邮件地址上强制执行唯一性,以便将其用作候选键。

You will find that users will want to change their email address, or anything really which they can see, so you should as good practice have an identifier which cannot be changed.

您会发现用户希望更改他们的电子邮件地址,或者他们可以看到的任何内容,因此您应该尽可能地使用无法更改的标识符。

Dealing with numbers in sql command object would not really be any more error prone then using the actual email address, if anything I would think it would be less error prone.

在sql命令对象中处理数字实际上不会更容易出错,然后使用实际的电子邮件地址,如果有什么我会认为它不会出错。

#5


1  

Your disadvantage is not a disadvantage. Using numbers with sql is not more or less a problem than using emails or anything else for the matter.

你的缺点不是缺点。与使用电子邮件或任何其他内容相比,使用带有sql的数字并不是一个问题。

On the other hand your advantage is quite a strong one, you might want to associate users with each other, different emails with one user account, etc. and always using the email will make things harder.

另一方面,您的优势非常强大,您可能希望将用户彼此关联,使用一个用户帐户关联不同的电子邮件等,并且始终使用电子邮件会使事情变得更难。

Think also of urls including user identication, an ID is much easier to handle there than an email where you have to think about the proper url endocing.

还要考虑包括用户身份验证在内的网址,ID比在电子邮件中更容易处理,您需要考虑正确的网址拦截。

So in favour of flexiblity and ease of use, I would strongly recommend a unique userID.

因此,为了支持灵活性和易用性,我强烈建议使用唯一的用户ID。

#6


0  

Just some points to consider.

只需要考虑一些要点。

  • How will you validate the email address?
  • 您将如何验证电子邮件地址?

  • How do you ensure that it is really unique (I don't always use my real address e.g. m.mouse at disney.com
  • 你如何确保它真的是独一无二的(我并不总是使用我的真实地址,例如在disney.com上的m.mouse

  • I like to use a unique key generated by the database to identify the record and then add attributes which are out of my control separately
  • 我喜欢使用数据库生成的唯一键来标识记录,然后单独添加不受我控制的属性

  • A person's email can change but the id will not
  • 一个人的电子邮件可以更改,但ID不会

#7


0  

Unique numbers. As well as the reasons identified, I think it would be less error prone than using an email address. Shorter, no funny characters, easier to validate, etc.

唯一的数字。除了确定的原因之外,我认为它比使用电子邮件地址更不容易出错。更短,没有搞笑角色,更容易验证等。