在企业应用程序中使用 MS SQL Identity 是一种好的做法吗？创建业务逻辑和将数据库从一个迁移到另一个不是很困难吗？
问问题
8869 次
5 回答
14
就个人而言，我不能没有身份列并在任何地方使用它们，但是有一些理由考虑不使用它们。
最初不使用身份列AFAIK的主要原因是由于分布式多数据库模式（断开连接）使用复制和/或各种中间件组件来移动数据。只是没有可用的分布式同步机制，因此没有可靠的方法来防止冲突。由于 SQL Server 确实支持分发 ID，因此这种情况发生了显着变化。但是，它们的使用可能仍然无法映射到更复杂的应用程序控制复制方案。
他们可以泄露信息。帐户 ID、发票号码等。如果我每个月都收到您的发票，我可以大致了解您发送的发票数量或您拥有的客户数量。
我一直在合并客户数据库时遇到问题，而且各方仍希望保留他们的旧帐号。这有时让我质疑我对身份字段的依赖:)
像大多数事情一样，最终的答案是“取决于”特定情况的细节在你的决定中必然会占据很大的比重。
于 2009-05-30T05:52:17.703 回答
11
是的，它们工作得很好，很可靠，并且表现最好。与非身份字段相比，使用身份字段的一大好处是它们可以处理多个调用者尝试保留新 ID 的所有复杂并发问题。这对代码来说似乎是微不足道的，但事实并非如此。
下面的这些链接提供了一些关于身份字段的有趣信息，以及为什么您应该尽可能使用它们。
于 2009-05-30T04:58:50.840 回答
5
是的。
它们通常按预期工作，您可以使用DBCC CHECKIDENT命令来操作和使用它们。
最常见的身份概念是提供一个有序的数字列表，作为主键的基础。
编辑：我对填充因子错了，我没有考虑到所有插入都会发生在 B 树的一侧。
此外，在您修改后的问题中，您询问了从一个数据库迁移到另一个数据库的问题：
只要迁移是单向复制，身份就完全没问题。如果您有两个需要相互复制的数据库，UniqueIdentifier 列可能是您最好的选择。
请参阅：您何时真正被迫使用 UUID 作为设计的一部分？讨论何时在数据库中使用 UUID。
于 2009-05-30T04:27:59.387 回答
5
问题总是：
您实际从一个数据库迁移到另一个数据库的可能性有多大？如果您正在构建一个多数据库应用程序，那就是另一回事了，但大多数应用程序永远不会被移植到新的数据库中游——尤其是当它们开始使用像 SQL Server 这样强大的东西时。
身份构造非常好，您不应该使用它的理由非常少。如果你有兴趣，我写了一篇关于身份价值的一些常见神话的博客文章。
于 2009-05-30T05:01:12.210 回答
1
关于身份的好文章，http://www.simple-talk.com/sql/t-sql-programming/identity-columns/
IMO，现在很少需要迁移到另一个 RDBMS。即使需要，开发可移植应用程序的最佳方式是开发一层存储过程，将您的应用程序与专有功能隔离开来：
于 2009-05-31T21:51:51.890 回答