在不定义主键的情况下创建SQL数据库

Question

因此，在我的工作环境中，我们不使用SQL Server定义的“主键”。换句话说，我们不会右键单击列并选择“设置为主键”。

但是我们仍然有主键，我们只使用一个唯一的ID列。在存储过程中，我们使用它们来访问数据，就像在任何关系数据库中一样。

我的问题是，除了在SQL Server中定义主键之外的内置功能，例如实体框架内容等。使用“主键”功能而不仅仅使用唯一ID列和使用您自己的存储过程访问您的表？

我看到的最大缺点（除了能够使用实体框架之类的东西之外）是你必须在心理上跟踪或以其他方式跟踪哪些ID与哪些表相关。

Answer 1

关于PRIMARY KEY约束没有任何“特殊”。它只是一个唯一性约束，您可以通过使用UNIQUE NOT NULL语法来定义键来实现相同的结果。

但是，出于数据完整性的原因，唯一性约束（即一般的密钥，而不是“主要”密钥）非常重要。它们确保您的数据是唯一的，这意味着可以从您的数据中获得合理，有意义的结果。从包含重复数据的数据库中获取准确结果非常困难。此外，需要使用唯一性约束来强制表之间的引用完整性，这是数据完整性的另一个非常重要的方面。数据完整性差是一个数据管理问题，每年花费企业数十亿美元，这是密钥重要性的底线。

另一个原因是唯一索引很重要：查询优化和性能。唯一索引可提高查询性能。如果您的数据应该是unqiue，那么在其上创建一个唯一索引将为查询优化器提供为您的查询选择一个好的执行计划的最佳机会。

Answer 2

我认为缺点是根本不使用主键，并且使用唯一的键约束来处理它不打算做的事情。

唯一键：您可以拥有其中许多键。它们旨在提供一种确定行间唯一性的方法。

主键：像汉兰达一样，只能有一个。它的目的是识别表的行。

我想不出任何不使用主键的好理由。我的意见是没有主键，你的表实际上不是一个表。这只是一块数据。

跟进：如果你不相信我，请看看这个问过一堆DBA的人是否可以不使用主键。

Is it OK not to use a Primary Key When I don't Need one

Answer 3

你的问题有哲学和实际的答案。

实用答案是使用主键约束强制执行“not null”和“unique”。这可以保护您免受应用程序级别的错误。

哲学答案是，您希望开发人员在尽可能高的抽象级别上运行，这样他们在尝试解决问题时就不必充满细节。

主键和外键是抽象，允许我们对基础数据模型做出假设。我们可以根据（业务）实体及其关系来思考。

在您的工作场所，您迫使开发人员根据表，索引和约定进行思考。您不再考虑“客户”和“订单”和“订单项”，而是关于代表这些商业实体的软件工件，以及“我们始终通过GUID和唯一索引的组合来表示唯一性”规则。在大多数应用中，这种心智模型已经足够复杂了;你只是让自己变得更难，特别是在将新开发人员带入团队时。