每个表都应该有一个主键吗？

在数据库设计中，每个表是否应该有一个主键一直是一个有争议的问题。一些人认为每个表都应该有一个主键，而其他人则持不同意见。但无论如何，我们需要考虑到问题出现的原因以及解决方法。

问题的出现主要是因为对于主键的定义和作用的理解不同。在上述讨论中，某些情况下主键可以应用于多个列，而不仅仅是单个列。这意味着主键可以是由多个列组成的组合键。例如，在一个表中，主键可以是(Owner, Friend)这两个列的组合。尤其是当Owner和Friend是对应于用户表的外键时，而不仅仅是实际的姓名时，这种情况更为常见。有些人还提到，他们习惯将主键命名为"Id"，并使用类似(OwnerId, FriendId)这样的命名方式。

对于是否每个表都应该有一个主键的问题，我们可以通过阅读一些相关的文章来了解更多信息。有一篇文章提到了关于数据库范式的主题，可以通过这个链接进行查看：http://michaeljswart.com/2011/01/ridiculously-unnormalized-database-schemas-part-zero/。

另一个问题是关于主键的唯一性的。某些情况下主键必须具有唯一的值，而Owner和Friend这两个列可能会有许多重复的值。对于这种情况，有人建议将Owner和Friend设置为索引而不是主键。当然，如果确实需要保证唯一性，可以像之前提到的那样，添加一个自增列作为主键。

此外，还有一些对于使用非技术列作为主键的争论。有人认为，非技术列是指代表你正在建模的领域数据的列，如"Owner"和"Friend"。而技术列是一些不包含此类数据的辅助列，比如一个整数的"ID"，只用于关系的内部处理。这些列通常不直接展示给访问数据库的应用程序用户。因此，对于关系表，有些人喜欢使用由外键组成的复合主键，如(OwnerId, FriendId)。

每个表是否应该有一个主键取决于具体的需求和设计理念。有些人认为每个表都应该有一个主键，而有些人则更倾向于根据具体情况来决定是否需要主键，以及主键的定义方式。在设计数据库时，我们需要仔细考虑表的结构和关系，并根据具体的需求来确定是否需要主键以及如何定义主键。

每个表都应该有一个主键吗？

这个问题的出现的原因是关于如何选择主键的讨论。在给出的内容中，有一些人提到应该使用技术性的主键，如"ID"，而另一些人则认为应该使用自然主键，即外键的组合。这是一个关于选择合适的主键的讨论。

解决方法是根据具体的情况进行选择。有人建议使用自然主键，即外键的组合，这样可以确保唯一性。还有人建议使用技术性的主键，如自增列。这样可以避免一些问题，例如在已有记录中更改外键的内容。

选择主键的方法取决于具体的需求和情况。有些情况下，使用自然主键可能是合适的，而在其他情况下，使用技术性主键可能更好。这需要根据具体的数据模型和业务需求进行权衡和决策。

以上就是关于每个表是否应该有一个主键的讨论和解决方法的整理。根据讨论的内容，选择主键应该根据具体情况进行决策，以满足数据模型和业务需求。

每张表都应该有一个主键。

你应该创建一个代理键，也就是一个自动递增的主键字段。

你还应该将“Friend”字段作为一个外键引用到那个自动递增字段上。

如果你认为未来可能需要“重新设置主键”，你可以考虑使用自然键，即能自然标识你的数据的字段。关键是在编码时始终使用自然标识符，然后在这些自然键上创建唯一索引。如果将来需要重新设置主键，你可以这样做，因为你的唯一索引保证了数据的一致性。

我只会在绝对必要的情况下这样做，因为它增加了代码和数据模型的复杂性。

请问“Friend”的外键必须引用tbl_user还是tbl_friendship中的自动递增id字段？如果是tbl_friendship，为什么？