每个表都应该有一个主键。无论是整数、GUID还是“设置名称”列，都没有关系。类型取决于应用程序的要求。理想情况下，如果要将表连接到另一个表，最好使用GUID或整数作为主键。

However, there may be some situations where having a database table without an integer primary key is necessary or preferred. One possible reason is when the data being stored in the table does not require a unique identifier or when the primary key would not provide any meaningful value for the data.

然而，有些情况下，可能需要或更喜欢在数据库表中没有整数主键。一个可能的原因是当存储在表中的数据不需要唯一标识符，或者当主键对数据没有提供任何有意义的值时。

In such cases, alternative solutions can be used to ensure data integrity and efficient querying. One option is to use a composite primary key, which consists of multiple columns that together uniquely identify a row. This can be useful when no single column can serve as a unique identifier, but a combination of columns can. For example, a table storing customer orders may use a composite primary key consisting of the customer ID and order ID columns.

在这种情况下，可以使用替代方案来确保数据的完整性和高效的查询。一种选择是使用复合主键，它由多个列组成，这些列一起唯一标识一行。当没有单个列可以作为唯一标识符时，但是列的组合可以时，这将非常有用。例如，存储客户订单的表可以使用由客户ID和订单ID列组成的复合主键。

Another approach is to use a unique constraint on a non-primary key column to ensure data uniqueness. This can be useful when there is a column that can serve as a unique identifier, but it is not suitable as the primary key. For instance, a table storing user emails may have an email column with a unique constraint to ensure that each email address is unique.

另一种方法是在非主键列上使用唯一约束来确保数据的唯一性。当存在一个列可以作为唯一标识符时，但不适合作为主键时，这将非常有用。例如，存储用户电子邮件的表可能具有一个电子邮件列，其中包含一个唯一约束，以确保每个电子邮件地址都是唯一的。

In conclusion, while it is generally recommended to have a primary key in every database table, there may be situations where it is not necessary or preferred. In such cases, alternative solutions like composite primary keys or unique constraints on non-primary key columns can be used to ensure data integrity and uniqueness. The choice of approach depends on the specific requirements and nature of the data being stored.

有没有没有整数主键的数据库表的好原因？

数据库表不需要具有自定义键的最明显的例子是多对多关系和标签系统。对于多对多关系，可以使用两个外键作为复合主键来实现，而不需要使用整数主键。这样可以避免创建冗余的唯一约束，同时还可以确保不会有两个具有相同拼写的标签。此外，依赖于标签的其他表已经有了标签文本，不需要再加入标签表来获取文本。

对于标签系统，可以使用标签文本作为主键，而不是使用整数主键。这样做有以下优点：可以确保标签的唯一性，无需添加冗余的唯一约束；可以防止两个不同的标签具有相同的拼写；依赖于标签的其他表已经有了标签文本，不需要再加入标签表来获取文本。

对于标签系统，还需要一个标签表作为允许的标签的查找表。即使可能没有使用每个标签的文章，但仍然需要列出允许的标签，例如在用户界面中填充菜单。而且，使用SELECT Tag FROM Tags比SELECT DISTINCT Tag FROM ArticlesTagged更快。

需要注意的是，这种设计会在标签表和标签关联表中存储标签文本两次。如果存储空间很重要，就不会选择这种设计，而是选择其他优点。

有没有没有整数主键的数据库表的好理由？

在单个数据库解决方案中，一个例子是如果你有一个国家表，使用ISO 3166-1-alpha-2国家代码作为主键可能更有意义，因为这是一个国际标准，使查询更加可读（例如，CountryCode = 'GB'而不是CountryCode = 28）。类似的论点也可以应用于ISO 4217货币代码。

在使用复制的SQL Server数据库解决方案中，使用UNIQUEIDENTIFIER键更合理，因为GUID在某些类型的复制中是必需的（并且如果有多个源数据库，避免键冲突也更容易！）。

你说得对，这是一个很好的理由。对我来说，在这种情况下，我仍然会使用自增主键，并在国家代码上添加唯一约束。此外，您可以为复制使用非主键GUID。只是一些想法。

- 我们最初在我们的国家表上使用了INT主键，但它变得比使用国家代码更痛苦，所以进行了重构。是的，你是对的，ROWGUIDCOL不一定是主键，但在我看来，通常将其设置为主键是有意义的。

我佩服你能提出应该始终使用主键的论点，但我喜欢你的反例。这些基本上是永远不会被修改的外部标识符，因此作为它们自己的主键是有效的。

我个人认为查询的可读性不是一个特别好的理由。虽然ISO标准代码可能是你能得到的最好的例子，但国家的ISO代码更有可能发生变化，而不是替代键的变化。

原因：

- 使用国际标准代码作为主键可以使查询更容易理解

- 在使用复制的解决方案中，使用GUID作为主键可以避免键冲突

解决方法：

- 对于国家表，可以使用ISO国家代码作为主键，并在代码上添加唯一约束

- 对于复制的解决方案，可以使用非主键GUID作为键，以避免键冲突