为什么aspnet_users使用guid作为id而不是递增int？帮助扩展用户领域的奖励积分
为什么aspnet_users使用guid作为id而不是递增int？
还有什么理由不在其他表中使用它作为主键？这感觉有点奇怪，因为我知道我过去使用过的大多数应用程序都只使用普通的 int 系统。
我也即将开始使用这个 id 来匹配额外的用户首选项等的扩展详细信息表。我还考虑使用带有 guid 和 int 的链接表，但决定这样做，因为我不认为我实际上需要将用户 ID 作为公共 int。
虽然我想要 int （感觉更容易进行用户查找等 stackoverflow.com/users/12345/user-name ），因为我只需要用户名，但我认为我不需要携带这个item 周围，并且当我需要查找 users int 时会导致查找的额外复杂性。
感谢您对此提供的任何帮助。
Why does aspnet_users use guid for id rather than incrementing int?
Also is there any reason no to use this in other tables as the primary key? It feels a bit odd as I know most apps I've worked with in the past just use the normal int system.
I'm also about to start using this id to match against an extended details table for extra user prefs etc. I was also considering using a link table with a guid and an int in it, but decided that as I don't think I actually need to have user id as a public int.
Although I would like to have the int (feels easier to do a user lookup etc stackoverflow.com/users/12345/user-name ) , as I am just going to have the username, I don't think I need to carry this item around, and incure the extra complexity of lookups when I need to find a users int.
Thanks for any help with any of this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它确保断开连接的系统之间的唯一性。任何可能需要与另一个先前未连接的数据存储进行交互的数据存储都可能会遇到冲突 - 例如，它们都使用
int来识别用户，现在我们必须经过复杂的解析过程来为该数据选择新的 ID。冲突的，并相应地更新所有参考文献。在 SQL 中使用标准唯一标识符（使用 newid()）作为主键的缺点是 GUID 不是连续的，因此当创建新行时，它们会插入到物理数据库页中的某个任意位置，而不是附加到结尾。对于具有大量插入率的系统来说，这会导致严重页面碎片。可以使用 newsequentialid() 来纠正它。我在此处讨论了更多详细信息。
一般来说，最佳实践是使用 newsequentialid() 作为 GUID 主键，或者不使用 GUID 作为主键。您始终可以拥有一个存储 GUID 的辅助索引列，您可以使用它来保持引用的唯一性。
It ensures uniqueness across disconnected systems. Any data store which may need to interface with another previously unconnected datastore can potentially encounter collisions - e.g. they both used
intto identify users, now we have to go through a complex resolution process to choose new IDs for the conflicting ones and update all references accordingly.The downside to using a standard uniqueidentifier in SQL (with newid()) as the primary key is that GUIDs are not sequential, so as new rows are created they are inserted at some arbitrary position in the physical database page, instead of appended to the end. This causes severe page fragmentation for systems that have any substantial insert rate. It can be corrected by using newsequentialid() instead. I discussed this in more detail here.
In general, its best practice to either use newsequentialid() for your GUID primary key, or just don't use GUIDs for the primary key. You can always have a secondary indexed column that stores a GUID, which you can use to keep your references unique.
GUID 作为主键在某些并不真正（不想或不知道）关心其底层数据库的程序员群体中非常流行。
GUID 很酷，因为它们（几乎）保证是唯一的，并且您可以在 .NET 代码中的客户端应用程序上“提前”创建它们。
不幸的是，这些人并没有意识到这些选择在 SQL Server 方面的可怕缺点（可怕的索引碎片，从而导致性能损失）。很多程序员真的一点也不关心......然后责怪SQL Server慢得像条狗。
如果您想使用 GUID 作为主键（它们确实有一些非常好的用途，正如 Rex M. 指出的那样 - 主要在复制场景中），那么可以，但请确保使用 INT IDENTITY 列作为集群键SQL Server 最大限度地减少索引碎片和性能损失。
Kimberly Tripp，“SQL Server 索引女王”，有很多关于该主题的非常好的和富有洞察力的文章 - 请参阅我最喜欢的一些文章：
以及她在她的博客上发布的基本上都是值得一读。
GUIDs as a primary key are quite popular with certain groups of programmers who don't really (don't want to or don't know to) care about their underlying database.
GUIDs are cool because they're (almost) guaranteed to be unique, and you can create them "ahead of time" on the client app in .NET code.
Unfortunately, those folks aren't aware of the terrible downsides (horrendous index fragmentation and thus performance loss) of those choices when it comes to SQL Server. Lots of programmer really just don't care one bit..... and then blame SQL Server for being slow as a dog.
If you want to use GUIDs for your primary keys (and they do have some really good uses, as Rex M. pointed out - in replication scenarios mostly), then OK, but make sure to use a INT IDENTITY column as your clustering key in SQL Server to minimize index fragmentation and thus performance losses.
Kimberly Tripp, the "Queen of SQL Server Indexing", has a bunch of really good and insightful articles on the topic - see some of my favorites:
and basically anything she ever publishes on her blog is worth reading.