如果我有一个用户可以标记另一个用户帖子并且无法撤消或更改的网站，我是否需要拥有主键？我的所有选择都在post_id上，并带有where子句以查看用户是否已标记它。
答案 0 :(得分：9)
在您的其他一些帖子中，我觉得您试图避免在表中添加主键的原因是为了节省空间。
不要这样想。
如果不首先测试它们以确定它们是否真正有效，那么进行非标准优化就是一个坏主意。您是否运行了一些测试，通过省略此表中的主键来显示您在数据库中节省了大量空间？或者你只是猜测？
使用主键并不一定意味着您将使用更多空间。根据数据库的不同，如果省略主键，它可能会为您添加一个隐藏字段（例如，如果您在MySQL / InnoDB中没有PK，它会在包含6字节行ID的合成列上添加隐藏的聚簇索引值（source））。如果您确实使用主键，而不是添加新列，则可以选择一些您知道应该是唯一的现有列。它不会占用更多空间，只是意味着数据将以不同的顺序存储，以便于搜索。
当您添加索引时，该索引将占用额外的空间，因为索引基本上只是表的几列的副本，加上返回原始表中的行的链接。还记得数据库在没有PK时使用的隐藏列吗？那么现在它必须使用它来查找你的行，所以你也会在你的索引中得到它的副本。如果您使用主键，那么您可能不需要添加一个索引，因此实际上是在这里节省空间。
除此之外，如果您的桌面上没有主键，一些有用的数据库工具将无法正常工作。你将会在你离开后惹恼每个必须维护你的数据库的人。
那么告诉我，为什么你认为没有一个是个好主意？
答案 1 :(得分：4)
主键与数据是否可以更改无关 - 它是整行的单一参考点，可以更快地查找和/或更改数据。
我的所有选择都在post_id上，并带有where子句以查看用户是否已标记它。
您需要提供有关业务规则的更多信息。例如，系统是否应支持多个标记同一帖子的用户？
如果答案是“否”，那么我会建模一个POST_STATUS_CODE表，并在POSTS表中为表提供外键。
如果答案是“是”，那么我仍然会有一个POST_STATUS_CODE表格，但还有一个表格，用于关联POSTS和POST_STATUS_CODE表格 - 比如POSTS_STATUS_XREF。< / p>
我有一个post_flag表，其中包含post_id，user_id（标记了它）和flag_type（ATM作为字节）。在这种情况下，我没有看到PK如何使它更快，但我想它每行需要4或8个字节。我在考虑索引post_id。如果我这样做，我还应该创建PK吗？
至少，我会将主键组合成：
post_id user_id 原因是主键确保不会出现重复。
主键可以由多个列组成 - 这称为复合键。这意味着这对值是唯一的。 IE：您不能拥有多个1, 1值的组合，但您可以拥有1,2，1,3等（反之亦然）。尝试添加重复项将导致重复的主键错误。
答案 2 :(得分：2)
主键有助于加快查找和连接速度，所以如果可以的话，总是很好。
答案 3 :(得分：2)
您不需要需要主键，即使用户要修改行也是如此。每次查询该表时，主键都会优化性能。如果您认为您的表格会大于大约一千行左右，那么设置主键会显着提升性能。
不创建主键的唯一好处就是它意味着你不必创建一个主键，我认为这是公平的:-P
你现在可以不打扰创建一个。您可以随时添加一个。没有大碍。不要让任何人欺负你认为你现在必须创建一个主键！你会很快看到它非常缓慢:-P然后你就可以在那一点上添加主键。如果到那时你没有太多重复:-P
答案 4 :(得分：1)
最好有一个，如果只是因为你可能需要手动删除偶尔的记录（例如重复记录），并且应该有一个唯一的标识符。
答案 5 :(得分：1)
简单的答案是肯定的。每个表都应该有一个主键（至少由一列组成）。没有一个会有什么好处？
答案 6 :(得分：0)
在这种情况下，你可能会在没有一个人的情况下离开，但我还是倾向于在那里抛出一把主键，只是因为它相对简单，如果需求发生变化，可以节省返工。 / p>
答案 7 :(得分：0)
软件要求可能会迅速变化。客户可能会引入新的要求。因此，拥有主键可能很有用，因为在这种情况下，您可以完全消除不必要的数据迁移。
答案 8 :(得分：0)
请阅读："Is it OK not to use a Primary Key When I don’t Need one?“
是的，您确实需要主键。
如果您认为不这样做，也可以使用文本文件进行存储，因为这意味着您不理解它们...