在企业应用程序中使用MS SQL Identity的良好做法吗？是不是在创建业务逻辑和将数据库从一个迁移到另一个时遇到了困难？
答案 0 :(得分：14)
就我个人而言，我不能没有身份列并且在任何地方使用它们，但是有一些理由考虑不使用它们。
原则上，不使用标识列AFAIK的主要原因是由于使用复制和/或各种中间件组件分布的多数据库模式（断开连接）来移动数据。没有可用的分布式同步机器，因此没有可靠的方法来防止冲突。这已经发生了重大变化，因为SQL Server确实支持分发ID。但是，它们的使用仍然可能无法映射到更复杂的应用程序控制的复制方案。
他们可以泄露信息。帐户ID，发票号码等。如果我每个月都会收到您的发票，我可以将您发送的发票或客户的数量包括在内。
我总是遇到问题，合并客户数据库，所有方面仍然希望保留旧帐号。这有时让我质疑我对身份字段的依赖：）
与大多数事情一样，最终的答案是“它取决于”特定情况的细节应该在你的决定中占很大的份量。
答案 1 :(得分：10)
是的，它们运作良好且可靠，并且表现最佳。使用身份字段与非身份字段的一大好处是，它们可以处理尝试保留新ID的多个呼叫者的所有复杂并发问题。这似乎对代码来说是微不足道的，但事实并非如此。
下面的这些链接提供了一些有关身份字段的有趣信息，以及为什么要尽可能使用它们。
答案 2 :(得分：5)
是
它们通常按预期工作，您可以使用DBCC CHECKIDENT命令来操作和使用它们。
身份最常见的想法是提供一个有序的数字列表，作为主键的基础。
编辑：我对填充因子错了，我没有考虑到所有插入都会发生在B树的一侧。
此外，在修订后的问题中，您询问了从一个数据库迁移到另一个数据库的问题：
只要迁移是单向复制，身份就完全没问题。如果您有两个需要相互复制的数据库，那么UniqueIdentifier列可能是您最好的选择。
有关何时在数据库中使用UUID的讨论，请参阅：When are you truly forced to use UUID as part of the design?。
答案 3 :(得分：5)
问题始终是：
您实际从一个数据库迁移到另一个数据库的可能性有多大？如果你正在构建一个多数据库应用程序，这是一个不同的故事，但是大多数应用程序都不会被移植到新的数据库中游 - 特别是当他们开始使用像SQL Server一样健壮的东西时。
身份构造非常好，而且你不应该使用它的原因很少。如果你有兴趣，我写了一篇关于身份价值的一些常见神话的博客文章。
The IDENTITY Property: A Much-Maligned Construct in SQL Server
答案 4 :(得分：1)
关于身份的好文章，http://www.simple-talk.com/sql/t-sql-programming/identity-columns/
IMO，这些天很少需要迁移到另一个RDBMS。即使需要，开发便携式应用程序的最佳方法是开发一层存储过程，将应用程序与专有功能隔离开来：