If I don't need a primary key should I not add one to the database?
如果我不需要主键,我不应该添加一个数据库吗?
12 个解决方案
#1
13
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.
你需要一个表来理解。
#2
40
You do need a primary key. You just don't know that yet.
你需要一个主键。你还不知道。
#3
3
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.
如果您不需要主键,请不要使用主键。我通常需要主键,所以我经常使用它们。如果您有相关的表,您可能需要主键和外键。
#4
2
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.
您还应该知道,如果您不这样做,某些数据库系统会为您创建主键,因此您无法根据引擎中的内容节省那么多。
#5
2
No, unless you can find an example of, "This database would work so much better if table_x didn't have a primary key."
不,除非你能找到一个例子,“如果table_x没有主键,那么这个数据库会好得多。”
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.
如果不需要性能,数据完整性和规范化,您可以争论永不使用主键。可能不需要安全和备份/恢复功能,但最终,你穿上你的大男孩裤子并加入数据库实现的真实世界。
#6
1
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.
什么时候不需要唯一地识别表中的记录?几乎从不。对于像审计日志表这样的事情,我之前已经这样做了。不会更新或删除的数据,也不会受到任何限制。基本结构化的日志记录
#7
0
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.
主键始终有助于查询性能。因此,如果您需要使用“密钥”查询“外键”,或者用作查找,那么是,请使用外键。
#8
0
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?
为什么我要把主键放在那?
#9
0
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.
主键主要是正式定义以帮助引用完整性,但是如果表非常小,或者不太可能包含唯一数据,则它是不必要的开销。在表上定义索引通常可用于暗示主键而不正式声明主键。但是,您应该考虑定义主键对于开发人员和模式生成或SQL Dev工具非常有用,因为元数据有助于理解,并且某些工具依赖于此来正确定义模型中的主/外键关系。
#10
0
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)
如果你有一个连接2个不同表的N-M表,你可能没有“ID”字段,但是你可以通过你加入的两列中的值唯一地识别记录。 (复合主键)
Having a table without an primary key is against the first normal form, and has nothing to do in a relational DB
拥有没有主键的表是违反第一个普通形式的,并且在关系数据库中无关
#11
0
You should always have a primary key, even if it's just on ID. Maybe NoSQL is what you're after instead (just asking)?
你应该总是有一个主键,即使它只是在ID上。也许NoSQL就是你所追求的(只是问)?
#12
0
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.
我能想到的一个用例是一个日志记录类表,在其中你只需要一个接一个地转储一个条目(以便以后正确处理它们)。如果您要存储足够的数据来过滤相关消息(如日期),那么您可能不需要主键。当然,使用RDBMS是有问题的。
#1
13
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.
你需要一个表来理解。
#2
40
You do need a primary key. You just don't know that yet.
你需要一个主键。你还不知道。
#3
3
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.
如果您不需要主键,请不要使用主键。我通常需要主键,所以我经常使用它们。如果您有相关的表,您可能需要主键和外键。
#4
2
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.
您还应该知道,如果您不这样做,某些数据库系统会为您创建主键,因此您无法根据引擎中的内容节省那么多。
#5
2
No, unless you can find an example of, "This database would work so much better if table_x didn't have a primary key."
不,除非你能找到一个例子,“如果table_x没有主键,那么这个数据库会好得多。”
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.
如果不需要性能,数据完整性和规范化,您可以争论永不使用主键。可能不需要安全和备份/恢复功能,但最终,你穿上你的大男孩裤子并加入数据库实现的真实世界。
#6
1
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.
什么时候不需要唯一地识别表中的记录?几乎从不。对于像审计日志表这样的事情,我之前已经这样做了。不会更新或删除的数据,也不会受到任何限制。基本结构化的日志记录
#7
0
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.
主键始终有助于查询性能。因此,如果您需要使用“密钥”查询“外键”,或者用作查找,那么是,请使用外键。
#8
0
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?
为什么我要把主键放在那?
#9
0
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.
主键主要是正式定义以帮助引用完整性,但是如果表非常小,或者不太可能包含唯一数据,则它是不必要的开销。在表上定义索引通常可用于暗示主键而不正式声明主键。但是,您应该考虑定义主键对于开发人员和模式生成或SQL Dev工具非常有用,因为元数据有助于理解,并且某些工具依赖于此来正确定义模型中的主/外键关系。
#10
0
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)
如果你有一个连接2个不同表的N-M表,你可能没有“ID”字段,但是你可以通过你加入的两列中的值唯一地识别记录。 (复合主键)
Having a table without an primary key is against the first normal form, and has nothing to do in a relational DB
拥有没有主键的表是违反第一个普通形式的,并且在关系数据库中无关
#11
0
You should always have a primary key, even if it's just on ID. Maybe NoSQL is what you're after instead (just asking)?
你应该总是有一个主键,即使它只是在ID上。也许NoSQL就是你所追求的(只是问)?
#12
0
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.
我能想到的一个用例是一个日志记录类表,在其中你只需要一个接一个地转储一个条目(以便以后正确处理它们)。如果您要存储足够的数据来过滤相关消息(如日期),那么您可能不需要主键。当然,使用RDBMS是有问题的。