Asp.net 我走错方向了吗？

这是我的第一个MVC/LINQtoSQL应用程序。我在ASP.NET中使用现成的SQL成员身份通过我的系统跟踪用户

正如大多数人所知，UserId是一个guid，很好。然而，为了链接系统中其他用户创建的表，我决定使用username而不是userid。我这样做的原因是：

用户名是唯一的

它避免了我在处理db函数时必须进行额外调用 例如：我不必根据用户名查找userid来创建新的故事；我只需将User.Identity.Name插入到故事表中

现在我确实遇到了一些棘手的问题，这似乎与此有关。它在我的本地机器上运行得很好，但在主机上却不行。我不断地遇到这样的错误：

“System.InvalidCastException:指定的强制转换无效。位于System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager”

每当主机上发生数据库插入时，就会发生这种情况。如果我理解正确，这是一个错误，当您将一个非整数字段（在我的例子中是username）链接到另一个非整数字段表（aspnet_user中的username）时，当前会发生这种错误。虽然报告的bug看起来有点不同，但它们是否相似

在任何情况下，不管是不是MS bug，在我的表中存储用户名而不是用户名是个坏主意吗？如果是，为什么

更新

我只是想在这里添加一些上下文。人们提出的一个好观点是，如果我想允许用户在将来更改用户名，这是很危险的。完全正确

---

但是，此应用程序严重依赖用户名。每个用户只创建一个故事。然后，他们使用：mysite/username链接到自己的故事。因此，应用程序将永远不允许他们更改用户名。这可能会给那些只看到链接不再存在的人带来一场噩梦。

我使用了与您相同的方法，而且效果很好。您的应用程序表和成员数据库中的表之间是否存在关系？如果是这样的话，您可能希望删除这种关系。

我唯一的想法是为了将来验证您的应用程序，userid将为用户更改用户名提供灵活性，因为userid将保持不变（例如）。

---

但这必须符合您的应用程序要求。同样，需求往往会在没有开发人员控制的情况下发生变化。

请注意您对用户名唯一性的评论。安妮塔·塔克巴思和西摩·巴特斯结婚的那一刻，阿塔克巴思突然想要成为一对

---

只是一个想法

这是不好的，原因如下：

您提到避免额外的数据库调用。然而，通过连接表，并没有对数据库的“额外”调用。你可以说加入比不加入要昂贵。但是，很可能商店需要的用户信息比用户登录名更多（注意：用户名不是唯一的，用户登录名是唯一的）。因此，对于大多数数据库操作，您仍然需要加入

用户登录名有不同的长度，当它们用于加入时，它的性能不好

---

编辑：修改格式。我仍在学习如何使我的帖子看起来更好：-）

如果您实施此操作的原因是为了更方便地访问用户的GUID，我建议让FormsAuthentication.SetAuthCookie将用户的GUID用作name属性，并在整个应用程序中使用User.Identity.name

---

使用用户名作为唯一标识符可能会在将来产生不良后果。如果您希望允许用户在将来更改用户名，您将很难实现这一点。

很高兴知道我不是唯一一个。现在不存在链接。只是澄清一下-由于这个bug，我不再与我创建的表和aspnet_用户表有关系。这让我有点不安，但我认为这不应该是个问题。你刚才说得很好！对于我的应用程序，用户名永远不会更改。谢谢。是的，非常好-按照@Jakub所说的（但用更有趣的方式来表达）。我说的是用户登录名，所以它们是独一无二的。现在，关于加入的问题，对于selects是这样的，但是插入呢？所以我创建了一个新的故事，新的评论，等等。难道我不需要首先从用户名中获取用户名，然后插入吗？这就是我试图避免的。我通常不喜欢问这个问题，但我现在不得不问：你为什么要避免它？在大多数情况下，插入将明显少于选择。因此，性能在这里不应该是一个问题。如果没有表现，你还想避免什么？我觉得你是在用一个严肃的价格交易一些琐碎的东西。我想我只是采取了稍微简单一点、不那么防弹的方式，因为应用程序用户名是100%唯一的。我现在想不出它有什么坏处…仅供参考-我在我的原始帖子中添加了更多的上下文。一个稍微简单的方法是一旦用户通过身份验证，将id保留在会话中，并在需要时使用它。