Will you ever need to join this table to other tables? Do you need a way to uniquely identify a record? If the answer is yes, you need a primary key. Assume your data is something like a customer table that has the names of the people who are customers. There may be no natural key because you need the addresses, emails, phone numbers, etc. to determine if this Sally Smith is different from that Sally Smith and you will be storing that information in related tables as the person can have mulitple phones, addesses, emails, etc. Suppose Sally Smith marries John Jones and becomes Sally Jones. If you don't have an artifical key onthe table, when you update the name, you just changed 7 Sally Smiths to Sally Jones even though only one of them got married and changed her name. And of course in this case withouth an artificial key how do you know which Sally Smith lives in Chicago and which one lives in LA?

你说你没有自然的密钥，因此你也没有任何字段的组合来使其唯一，这使得人工密钥至关重要。

我发现，在没有天然密钥的情况下，人工密钥对于维护数据完整性是绝对必要的。如果您确实有一个自然键，您可以使用它作为键字段。但就我个人而言，除非自然键是一个字段，否则我仍然喜欢人工键和自然键上的唯一索引。如果你不放进去，你以后会后悔的。

为了证明未来，你真的应该这么做。如果你想复制它，你需要一个。如果你想把它加入到另一张桌子上，你的生活(以及那些明年不得不维持它的可怜的傻瓜们的生活)将会轻松得多。

如果你正在使用Hibernate，不可能创建一个没有主键的实体。如果您正在使用使用普通sql/ddl脚本创建的现有数据库，并且没有添加主键，则此问题可能会产生问题

不同意建议的答案。简短的回答是:不。

主键的作用是唯一地标识表上的一行，以便与另一个表形成关系。传统上，用于此目的的是一个自动递增的整数值，但也有一些变化。

但在某些情况下，例如记录时间序列数据，根本不需要这样的键，只需要占用内存。使一行唯一很简单……不需要!

举个小例子: 表A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

不需要主键。

表B:用户

Columns: Id, FirstName, LastName etc. 

用来作为LogData表的“外键”的主键(Id)。

我的职责是维护海外开发团队创建的应用程序。现在我在应用程序中有各种各样的问题，因为原始的数据库模式不包含一些表上的主键。所以请不要让别人因为你糟糕的设计而受苦。在表上设置主键总是一个好主意。

我总是有一个主键，即使一开始我还没有想到它的目的。有几次，当我最终需要在一个没有PK的表中输入PK时，总是会遇到更多的麻烦。我认为总是有一个人会有更多的好处。