我是否以错误的方式处理这个问题？
这是我的第一个 MVC/Linq to SQL 应用程序。我使用 ASP.NET 的开箱即用 SQL 成员身份来通过我的系统跟踪用户。
正如大多数人所知，UserId 是一个 guid，这很好。但是，为了链接系统中其他用户创建的表，我决定使用用户名而不是用户 ID。我这样做的原因是因为：
- 用户名无论如何都是唯一的
- 它使我不必在处理数据库函数时进行额外的调用。
例如：我不必根据用户名查找用户 ID 来创建新故事；我只是将 User.Identity.Name 插入故事表中。
现在我确实遇到了一些令人讨厌的并发症，这似乎与此有关。它在我的本地计算机上运行良好，但在主机上运行不佳。我不断收到这样的错误：
“System.InvalidCastException：指定的强制转换无效。在 System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager”...
每当主机上发生数据库插入时就会发生这种情况。如果我理解正确的话，这是当前当您将非整数字段（在我的例子中为用户名）链接到非整数字段（aspnet_user 中的用户名）的另一个表时发生的错误。虽然报告的错误看起来有点不同，但也许它们是相似的？
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback。 aspx?FeedbackID=351358
无论如何，无论是否是 MS 错误 - 在我的表中存储用户名而不是用户 ID 是一个坏主意吗？如果是，为什么？
更新
我只是想在这里添加更多背景信息。人们提出的一个很好的观点是，如果我想允许用户将来更改他们的用户名，这是危险的。完全有效！
然而，该应用程序严重依赖用户名。每个用户创建一个且仅一个故事。然后，他们使用 mysite/username 链接到他们的故事。因此，应用程序永远不会允许他们更改用户名。对于那些点击链接却发现它不再存在的人来说，这可能会带来一场潜在的噩梦。
This is my first MVC/Linq to SQL Application. I'm using the out of the box SQL Membership with ASP.NET to track users through my system.
As most of you know, the UserId is a guid, great. However, to link other user-created tables in the system, I decided to go with username instead of userid. The reason I did this was because:
- Username is unique anyway
- It prevents me from having to make an extra call when handling db functions.
So for example: I don't have to do a look up on the userid based on username to create a new story; I simply insert User.Identity.Name into the story table.
Now I did run into some nasty complication, which seems to be related to this. It worked fine on my local machine, but not on the host. I continually got an error that went something like this:
"System.InvalidCastException: Specified cast is not valid. at System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager"...
This happened whenever an insert on the db occurred on the host. If I understand correctly, this is a bug currently that happens when you link a non integer field (in my case username) to another table of a non integer field (username in aspnet_user). Although the bug reported seems a little bit different, maybe they are similar?
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=351358
In any case, MS bug or not - is storing the username instead of the userid in my tables a bad idea? If it is, why?
Update
I just wanted to add some more context here. A good point people are bringing up is that this is dangerous if I want to allow users to change their username in the future. Perfectly valid!
However, this application relies heavily on the username. Each user creates one and only one story. They then link to their story by using: mysite/username. Therefore, the application will never allow them to change their username. It would cause a potential nightmare for people who follow the link only to see it no longer exists.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
请注意您对用户名的评论是唯一的。安妮塔·塔克巴斯 (Anita Takeabath) 与西摩·巴茨 (Seymour Butts) 结婚的那一刻，阿塔克巴斯突然想要成为对接对象。
只是一个想法！
Be careful regarding your comment regarding usernames are unique. The minute Anita Takeabath gets married to Seymour Butts suddenly atakebath wants to be abutts.
Just a thought!
我用了和你一样的方法并且有效。您的应用程序表和成员资格数据库中的表之间是否存在关系？如果是这样，您可能想要删除这种关系。
I've used the same approach as you and it works. Do you have a relationship between your application table and the table from the membership db? If so, you may want to remove that relationship.
我唯一的想法是，为了让您的应用程序在未来得到证明，用户 ID 将为用户更改用户名提供灵活性，因为用户 ID 将保持不变（例如 SO）。
但这必须满足您的应用程序要求。然而，需求往往会在开发人员无法控制的情况下发生变化。
My only thought would be in order to future proof your application, the userid would offer flexibility in users changing their username, as the userid would remain constant (like SO for instance).
But that is something that has to fit your application requirements. Then again requirements often tend to change wihtout a developers control.
由于以下原因，它很糟糕：
您提到避免额外的数据库调用。但是，通过连接表，不会对数据库进行“额外”调用。你可以说加入比不加入成本更高。然而，很可能，商店需要比用户登录名更多的用户信息（注意：用户名不是唯一的，用户登录名是唯一的）。因此，对于大多数数据库操作，无论如何您都需要加入。
用户登录名长度不同，用于加入时效果不佳。
编辑：修改格式。我仍在学习如何让我的帖子看起来更好:-)
It's bad for the following reasons:
You mentioned avoiding extra database calls. However, by joining tables, there is no "extra" call to database. You can argue that joining is expensive than no joining at all. However, most likely, a store needs more user information than a user login name (note: user names are not unique, user login names are unique). So you need joining anyway for most database operations.
User login names have different length, it doesn't perform well when they are used in joining.
Edit: modified format. I am still learning how to make my post look better:-)
如果您实现此目的的原因是为了更轻松地访问用户的 GUID，我建议您的 FormsAuthentication.SetAuthCookie 使用用户的 GUID 作为名称属性，并在整个应用程序中使用 User.Identity.Name。
使用用户名作为唯一标识符可能会在将来产生不良后果。如果您希望允许用户将来更改他们的用户名，那么您将很难实现这一点。
If the reason you're implementing this is for easier access to the User's GUID, I suggest having your FormsAuthentication.SetAuthCookie use the users's GUID as the name property and use User.Identity.Name throughout your application.
Using username as the unique identifier could have bad consequences in the future. Should you want to allow the user change their username in the future, you will have a hard time implementing that.