如何正确创建复合主键 - MYSQL
这是我正在使用的密集设置的总体过度简化。 table_1
和 table_2
都有自动增量代理主键作为 ID。 info
是一个表,其中包含有关 table_1
和 table_2
的信息。
table_1 (id, field)
table_2 (id, field, field)
info ( ???, field)
我正在尝试决定是否应该将 info
的主键设为 table_1
和 table_2
中 ID 的组合。如果我要这样做,哪一个最有意义?
(在本例中,我将 ID 11209 与 ID 437 组合在一起)
INT(9)
11209437 (我可以想象为什么这很糟糕)VARCHAR(10)
11209-437DECIMAL (10,4)
11209.437
或者其他什么?
使用它作为 MYSQL MYISAM DB 上的主键可以吗?
Here is a gross oversimplification of an intense setup I am working with. table_1
and table_2
both have auto-increment surrogate primary keys as the ID. info
is a table that contains information about both table_1
and table_2
.
table_1 (id, field)
table_2 (id, field, field)
info ( ???, field)
I am trying to decided if I should make the primary key of info
a composite of the IDs from table_1
and table_2
. If I were to do this, which of these makes most sense?
( in this example I am combining ID 11209 with ID 437 )
INT(9)
11209437 (i can imagine why this is bad)VARCHAR (10)
11209-437DECIMAL (10,4)
11209.437
Or something else?
Would this be fine to use this as the Primary Key on a MYSQL MYISAM DB?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我会使用复合(多列)键。
这样,您也可以将 t1ID 和 t2ID 作为外键指向它们各自的表。
I would use a composite (multi-column) key.
This way you can have t1ID and t2ID as foreign keys pointing to their respective tables as well.
我不会将“info”表的主键设为其他表中两个值的组合。
其他人可以更好地阐明原因,但拥有一个实际上由两条信息组成的专栏感觉不对。如果出于某种原因您想对第二个表中的 ID 进行排序怎么办?如果您想计算任一表中的值出现的次数该怎么办?
我总是将它们保留为两个不同的列。您可以在 mysql 中使用两列主键 ...PRIMARY KEY(id_a, id_b)... 但我更喜欢使用两列唯一索引,并具有自动增量主键字段。
I would not make the primary key of the "info" table a composite of the two values from other tables.
Others can articulate the reasons better, but it feels wrong to have a column that is really made up of two pieces of information. What if you want to sort on the ID from the second table for some reason? What if you want to count the number of times a value from either table is present?
I would always keep these as two distinct columns. You could use a two-column primay key in mysql ...PRIMARY KEY(id_a, id_b)... but I prefer using a two-column unique index, and having an auto-increment primary key field.
语法为
CONSTRAINT constrain_name PRIMARY KEY(col1,col2,col3)
例如::CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
上面如果您在创建表时编写示例,则该示例将起作用,例如 ::
要将此约束添加到现有表,您需要遵循以下语法
the syntax is
CONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3)
for example ::CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
the above example will work if you are writting it while you are creating the table for example ::
to add this constraint to an existing table you need to follow the following syntax
假设您已经创建了一个表,现在您可以使用此查询来制作复合主键
Suppose you have already created a table now you can use this query to make composite primary key
除了个人设计偏好之外,在某些情况下人们还想使用复合主键。表可能有两个或多个提供唯一组合的字段,并且不一定通过外键的方式。
例如,美国每个州都有一组独特的国会选区。虽然许多州可能单独拥有一张 CD-5,但 50 个州中的任何一个州都不会拥有超过一张 CD-5,反之亦然。因此,为 Massachusetts CD-5 创建自动编号字段是多余的。
如果数据库驱动动态网页,则编写代码来查询两个字段的组合可能比提取/重新提交自动编号键要简单得多。
因此,虽然我没有回答最初的问题,但我当然很欣赏 Adam 的直接回答。
Aside from personal design preferences, there are cases where one wants to make use of composite primary keys. Tables may have two or more fields that provide a unique combination, and not necessarily by way of foreign keys.
As an example, each US state has a set of unique Congressional districts. While many states may individually have a CD-5, there will never be more than one CD-5 in any of the 50 states, and vice versa. Therefore, creating an autonumber field for Massachusetts CD-5 would be redundant.
If the database drives a dynamic web page, writing code to query on a two-field combination could be much simpler than extracting/resubmitting an autonumbered key.
So while I'm not answering the original question, I certainly appreciate Adam's direct answer.
复合主键是您想要与事实表创建多对多关系的地方。例如,您可能有一个假期租赁套餐,其中包含许多房产。另一方面,该房产也可以作为多个租赁套餐的一部分提供,可以单独使用,也可以与其他房产一起使用。在此场景中,您可以使用属性/包事实表建立属性和租赁包之间的关系。属性和包之间的关联是唯一的,您只能使用 property_id 与属性表和/或 package_id 与包表连接。每个关系都是唯一的,并且 auto_increment 键是多余的,因为它不会出现在任何其他表中。因此定义复合键就是答案。
Composite primary keys are what you want where you want to create a many to many relationship with a fact table. For example, you might have a holiday rental package that includes a number of properties in it. On the other hand, the property could also be available as a part of a number of rental packages, either on its own or with other properties. In this scenario, you establish the relationship between the property and the rental package with a property/package fact table. The association between a property and a package will be unique, you will only ever join using property_id with the property table and/or package_id with the package table. Each relationship is unique and an auto_increment key is redundant as it won't feature in any other table. Hence defining the composite key is the answer.
@AlexCuse我想将此作为评论添加到您的答案中,但在多次尝试在评论中添加换行符失败后放弃了。
也就是说,
t1ID
在table_1
中是唯一的,但这并不意味着它在INFO
表中也是唯一的。例如:
Table_1 具有:
ID 字段
1 个
2 B
Table_2 具有:
ID 字段
1 X
2 Y
INFO 然后可以有:
t1ID t2ID 字段
1 1 一些
1 2 数据
2 1 个
2 2 row
因此,在
INFO
表中,要唯一标识一行,您需要t1ID
和t2ID
@AlexCuse I wanted to add this as comment to your answer but gave up after making multiple failed attempt to add newlines in comments.
That said,
t1ID
is unique intable_1
but that doesn't makes it unique inINFO
table as well.For example:
Table_1 has:
Id Field
1 A
2 B
Table_2 has:
Id Field
1 X
2 Y
INFO then can have:
t1ID t2ID field
1 1 some
1 2 data
2 1 in-each
2 2 row
So in
INFO
table to uniquely identify a row you need botht1ID
andt2ID