当我不需要主键时，不使用主键可以吗
如果我不需要主键，我是否应该向数据库添加一个主键？
If I don't need a primary key should I not add one to the database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
如果我不需要主键，我是否应该向数据库添加一个主键？
If I don't need a primary key should I not add one to the database?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（12）
您确实需要一个主键。你只是还不知道而已。
You do need a primary key. You just don't know that yet.
主键唯一标识表中的一行。
事实上它的索引和/或集群是一个物理实现问题，与逻辑设计无关。
您需要一个表格才能有意义。
A primary key uniquely identifies a row in your table.
The fact it's indexed and/or clustered is a physical implementation issue and unrelated to the logical design.
You need one for the table to make sense.
如果您不需要主键，则不要使用主键。我通常有主键的需求，所以我通常会使用它们。如果您有相关表，您可能需要主键和外键。
If you don't need a primary key then don't use one. I usually have the need for primary keys, so I usually use them. If you have related tables you probably want primary and foreign keys.
是的，但只是在同样的意义上，如果您不打算发生事故，则可以不使用安全带。也就是说，当您需要它时，只需付出很小的代价就能获得巨大的好处，而且即使您认为自己不需要它，将来您也可能会需要它。不同之处在于，您需要主钥匙的可能性比发生车祸的可能性要大得多。
您还应该知道，如果您不这样做，某些数据库系统会为您创建主键，因此就引擎中发生的情况而言，您不会节省那么多。
Yes, but only in the same sense that it's okay not to use a seatbelt if you're not planning to be in an accident. That is, it's a small price to pay for a big benefit when you need it, and even if you think you don't need it odds are you will in the future. The difference is you're a lot more likely to need a primary key than to get in a car accident.
You should also know that some database systems create a primary key for you if you don't, so you're not saving that much in terms of what's going on in the engine.
不可以，除非您能找到“如果 table_x 没有主键，这个数据库会工作得更好”的示例。
如果不需要性能、数据完整性和规范化，您可以主张永远不要使用主键。可能不需要安全性和备份/恢复功能，但最终，您穿上大男孩裤子并加入数据库实施的现实世界。
No, unless you can find an example of, "This database would work so much better if table_x didn't have a primary key."
You can make an arguement to never use a primary key, if performance, data integrity, and normalization are not required. Security and backup/restore capabilities may not be needed, but eventually, you put on your big-boy pants and join the real world of database implementation.
是的，表应该始终有一个主键......除非您不需要唯一标识其中的记录。 （我喜欢做出绝对的陈述并立即反驳它们）
什么时候你不需要唯一标识表中的记录？几乎从来没有。我之前已经做过类似审计日志表之类的事情。不会更新或删除的数据，也不会受到任何方式的约束。本质上是结构化日志记录。
Yes, a table should ALWAYS have a primary key... unless you don't need to uniquely identify the records in it. (I like to make absolute statements and immediately contradict them)
When would you not need to uniquely identify the records in a table? Almost never. I have done this before though for things like audit log tables. Data that won't be updated or deleted, and wont be constrained in any way. Essentially structured logging.
主键始终有助于提高查询性能。因此，如果您需要使用“键”到“外键”进行查询，或者用作查找，那么可以，创建一个外键。
A primary key will always help with query performance. So if you ever need to query using the "key" to a "foreign key", or used as lookup then yes, craete a foreign key.
我不知道。我使用了几个表，其中只有一行和一列。永远只是一行和一列。没有外键关系。
为什么我要在上面放一个主键？
I don't know. I have used a couple tables where there is just a single row and a single column. Will always only be a single row and a single column. There is no foreign key relationships.
Why would I put a primary key on that?
主键主要是为了帮助引用完整性而正式定义的，但是如果表非常小，或者不太可能包含唯一数据，那么它是不必要的开销。
在表上定义索引通常可用于暗示主键，而无需正式声明主键。
但是，您应该考虑到定义主键对于开发人员和架构生成或 SQL 开发工具很有用，因为元数据有助于理解，并且某些工具依赖于此来正确定义模型中的主/外键关系。
A primary key is mainly formally defined to aid referencial Integrity, however if the table is very small, or is unlikely to contain unique data then it's an un-necessary overhead.
Defining indexes on the table can normally be used to imply a primary key without formally declaring one.
However you should consider that defining the Primary key can be useful for Developers and Schema generation or SQL Dev tools, as having the meta data helps understanding, and some tools rely on this to correctly define the Primary/foreign key relationships in the model.
嗯...
关系数据库中的每个表都需要一个主键。如前所述，主键是唯一标识记录的数据...
如果您有一个连接 2 个不同表的 NM 表，那么您可能会没有“ID”字段，但您可以通过以下方式唯一标识该记录：您加入的两列中的值。 （复合主键）
没有主键的表违反第一范式，并且与关系数据库无关
Well...
Each table in a relational DB needs a primary key. As already noted, a primary key is data that identies a record uniquely...
You might get away with not having an "ID" field, if you have a N-M table that joins 2 different tables, but you can uniquely identifiy the record by the values from both columns you join. (Composite primary key)
Having a table without an primary key is against the first normal form, and has nothing to do in a relational DB
您应该始终有一个主键，即使它只是在 ID 上。也许 NoSQL 才是您所追求的（只是问一下）？
You should always have a primary key, even if it's just on ID. Maybe NoSQL is what you're after instead (just asking)?
这在很大程度上取决于您是否确定不需要它。如果您有一点点疑问，请添加一个 - 您稍后会感谢自己。一个指标是您存储的数据是否可能在某个时刻与数据库中的其他数据相关。
我能想到的一个用例是一种日志记录表，您只需在其中一个接一个地转储一个条目（以便稍后正确处理它们）。如果您存储足够的数据来过滤掉相关消息（例如日期），那么您可能不需要主键。当然，为此使用 RDBMS 是有问题的。
That depends very much on how sure you can be that you don't need one. If you have just the slightest bit of doubt, add one - you'll thank yourself later. An indicator being if the data you store could be related to other data in your DB at one point.
One use case I can think of is a logging kind-of table, in which you simply dump one entry after the other (to properly process them later). You probably won't need a primary key there, if you're storing enough data to filter out the relevant messages (like a date). Of course, it's questionable to use a RDBMS for this.