我创建了新的应用程序。对于这个项目，我构建了一个登录页面。在存储用户信息的表中，我正在寻找一个保留用户ID的列。对于系统中的每个用户，此ID应该是唯一的。在网上浏览时，我发现了一些建议，但每个建议都有不同的问题。
在我的项目中，我在ColdFusion 2016和Microsoft SQL 2008中使用。最初我将在SQL中使用NEWID()为每个用户生成密钥，但有一些我不喜欢这样的事情。解。
首先，ID太长了，我不希望我的用户在搜索时输入这么长的值。
其次，我读到这会影响查询的性能并减慢我的数据库速度。
然后我考虑使用auto-increment id。在我看来，这个解决方案对于系统ID来说太简单了，可能会在将来引起一些冲突。例如，如果必须重新创建表，我不确定ID是否保持不变。所以我想知道为系统创建唯一ID的最佳做法是什么？我应该使用ColdFusion CreateUUID()吗？在我看来，这太长了。
如果有人知道最佳做法或有任何如何实现这一目标的例子，请告诉我。谢谢！
答案 0 :(得分：5)
与大多数其他事项一样 IT DEPENDS 。
似乎应该是这样一个简单问题的东西可以很快变得非常复杂。 INT甚至BIGINT明显小于GUID，但只有300k左右的记录，它不会对大小产生巨大影响，但是GUID {1}}因为您的PRIMARY KEY 将导致重大碎片。这肯定会影响您的索引，如果您需要最高性能，可能会导致查找问题。
如果高安全性是一个优先事项，那么使用顺序ID的一个坏处就是，当一个坏人发现你的id方案时，它会非常容易地通过你的用户进行计算。 GUID解决了这个问题，即使在多个系统中，两个人拥有相同GUID的机会也非常小。
SQL 2008确实有newsequentialid()，这有助于解决newid()的一些问题。它将显着减少碎片，但它仍然需要比INT更多的存储空间。 https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql
同样，这是一个需要您考虑的问题，尤其是它会如何影响您的系统。这最终是你必须在预期的系统中权衡的。
https://news.ycombinator.com/item?id=14523523
https://blogs.msdn.microsoft.com/sqlserverfaq/2010/05/27/guid-vs-int-debate/
你应该时刻关注特里普女士的建议。 https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/
虽然杰夫阿特伍德有不同意见。和Joe Celko一样。 https://blog.codinghorror.com/primary-keys-ids-versus-guids/
Google上有大量的链接，可以为您提供多方面的讨论。它真的开始接近宗教辩论。最终，我不认为这里的任何人可以告诉你最佳实践＆＃34;是。您必须在系统中尝试不同的方法，看看哪种方法最适合您的方法。