blocks|key|273058|text|复合主键在将它们用作其他表中的外键时提供了更好的性能，并减少了表的读取-有时它们可以是救命稻草。如果使用代理键，则必须转到该表以获取自然键信息。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|273059|例如(纯粹的例子-所以我们这里不是在讨论DB设计)，假设你有一个ORDER表和ORDER_ITEM。如果您使用ProductId和LineNumber+(UPDATE：正如佩德罗提到的OrderId或更好的OrderNumber)作为ORDER_ITEM中的组合主键，那么在SHIPPING的交叉表中，您将能够在SHIPPING_ORDERITEM中使用ProductId。这可以极大地提高您的性能，例如，如果您的产品用完了，需要找出该ProductId的所有产品，而不需要加入。|CODE|273060|另一方面，如果使用代理键，则必须进行连接，最终会得到效率非常低的执行计划，它必须对多个索引执行书签查找。|273061|参见more+on+bookmark+lookup，其中使用代理键成为一个主要问题。|273062|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/aa964133%2528v=sql.90%2529.aspx^0|4|M|0|W|5|13|A|1J|9|1T|A|2K|7|2V|B|39|A|3T|8|4C|I|62|9|25|6|0|W|F|0|A|F|2|4|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|H]|$9|10|A|11|B|H]|$9|12|A|13|B|H]|$9|14|A|15|B|H]|$9|16|A|17|B|H]|$9|18|A|19|B|H]|$9|1A|A|1B|B|H]|$9|1C|A|1D|B|H]|$9|1E|A|1F|B|H]|$9|1G|A|1H|B|H]|$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|I|3|J|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|M|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|N|$O|$5|P|Q|R|E|$S|T]]]]

Composite primary key provides better performance when it comes to them being used as Foreign keys in other tables and reduces table reads - sometimes they can be life savers. If you use surrogate keys, you have to go to that table to get natural key information.

For example (pure example - so we are not talking DB design here), lets say you have an <code>ORDER</code> table and <code>ORDER_ITEM</code>. If you use <code>ProductId</code> and <code>LineNumber</code> (UPDATE: and as Pedro mentioned <code>OrderId</code> or even better <code>OrderNumber</code>) as composite primary key in <code>ORDER_ITEM</code>, then in your cross table for <code>SHIPPING</code>, you would be able to have ProductId in the <code>SHIPPING_ORDERITEM</code>. This can massively boost your performance if for example you have run out of that product and need to find out all products of that <code>ProductId</code> that need to be shipped without a need to join.

On the other hand, if you use a surrogate key, you have to join and you end up with a very inefficient SQL execution plan where it has to do bookmark lookup on several indexes.

See <a href="http://msdn.microsoft.com/en-us/library/aa964133%28v=sql.90%29.aspx" rel="noreferrer">more</a> on bookmark lookup which using surrogate keys becomes a major issue.

blocks|key|3193052|text|就我个人而言，我更喜欢使用代理键。但是，在连接只包含来自另外两个表的in的表时(为了创建多对多关系)，组合键是可行的方法，因此将它们去掉会使事情变得更加困难。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3193053|有一个学派认为代理键总是不好的，如果你没有通过使用自然键来记录的唯一性，那么你就有一个糟糕的设计。我强烈反对这一点(例如，如果您没有存储SSN或其他一些唯一值，我建议您为person表提供一个自然键。)但许多人认为这对于适当的规范化是必要的。|3193054|有时，使用组合键可以减少连接到另一个表的需要。有时并非如此，所以有时组合键可以提高性能，有时它也会损害性能。如果键相对稳定，您可以在select查询上获得更快的性能。但是，如果它是像公司名称这样容易更改的东西，那么当公司A更改其名称时，您可能会处于痛苦的世界中，并且您必须更新一百万条相关记录。|3193055|在数据库设计中没有一刀切的方法。有时组合键是有用的，有时是可怕的。有时代理键有用，有时没用。|3193056|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Personally I prefer the use of surrogate keys. However, in joining tables that consist only of the ids from two other tables (to create a many-to-many relationships) composite keys are the way to go and thus taking them out would make things more difficult. 

There is a school of thought that surrogate keys are always bad and that if you don't have uniqueness to record through the use of natural keys you have a bad design. I strongly disagree with this (if you aren't storing SSN or some other unique value I defy you to come up with a natural key for a person table for instance.) But many people feel that it is necessary for proper normalization.

Sometimes having a composite key reduces the need to join to another table. Sometimes it doesn't. So there are times when a composite key can boost performance as well as times when it can harm performance. If the key is relatively stable, you may be fine with faster performance on select queries. However, if it is something that is subject to change like a company name, you could be in a world of hurt when company A changes it's name and you have to update a million associated records. 

There is no one size fits all in database design. There are time when composite keys are helpful and times when they are horrible. There are times when surrogate keys are helpful and times when they are not.

blocks|key|2979498|text|当您的主键是非代理键并且本质上是复合的，也就是说，可以分解为几个不相关的部分时，就需要组合键。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2979499|一些真实世界的例子：|2979500|2979501|多对多链接表，其中当tenant_id是每个实体的主键的一部分并且实体只能在同一租户内链接时，其中的主键由实体的键组成|unordered-list-item|offset|length|style|CODE|2979502|(受处理第三方数据的外部key).|2979503|Applications约束(具有已提供的主键)|2979504|2979505|请注意，从逻辑上讲，所有这些都可以使用UNIQUE约束(除了代理PRIMARY+KEY之外)来实现。|2979506|但是，有一些特定于实现的东西：|2979507|PRIMARY+KEY.|2979508|Some+|2979509|某些系统不允许FOREIGN+KEY引用除PRIMARY+KEY之外的任何内容系统将只在PRIMARY+KEY上聚集表，因此使组合成为|2979510|将提高组合上连接的查询的性能。|2979511|2979512|entityMap^0|0|0|0|A|9|0|0|0|0|J|6|W|B|0|0|0|B|0|0|7|B|L|B|18|B|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|18|8|@$H|19|I|1A|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1B|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|1C|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1E|8|@$H|1F|I|1G|J|K]|$H|1H|I|1I|J|K]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@$H|1L|I|1M|J|K]]|9|@]|A|$]]|$1|W|3|X|5|G|7|1N|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|G|7|1O|8|@$H|1P|I|1Q|J|K]|$H|1R|I|1S|J|K]|$H|1T|I|1U|J|K]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1V|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|14|$]]

Composite keys are required when your primary keys are non-surrogate and inherently, um, composite, that is, breakable into several non-related parts.

Some real-world examples:

<ul>
<li>Many-to-many link tables, in which the primary keys are composed of the keys of the entities related.</li>
<li>Multi-tenant applications when <code>tenant_id</code> is a part of primary key of each entity and the entities are only linkable within the same tenant (constrained by a foreign key).</li>
<li>Applications processing third-party data (with already provided primary keys)</li>
</ul>

Note that logically, all this can be achieved using a <code>UNIQUE</code> constraint (additional to a surrogate <code>PRIMARY KEY</code>).

However, there are some implementation specific things:

<ul>
<li>Some systems won't let a <code>FOREIGN KEY</code> refer to anything that is not a <code>PRIMARY KEY</code>.</li>
<li>Some systems would only cluster a table on a <code>PRIMARY KEY</code>, hence making the composite the <code>PRIMARY KEY</code> would improve performance of the queries joining on the composite.</li>
</ul>

blocks|key|3193079|text|非常简单的答案是数据完整性。如果数据是有用和准确的，那么密钥可能是必需的。拥有“自动生成的id”并不会消除对其他键的要求。另一种选择是不强制唯一性，并接受数据将被复制，并且几乎不可避免地包含异常并因此导致错误。你为什么要这么做？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3193080|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The very simple answer is data integrity. If the data is to be useful and accurate then the keys are presumably required. Having an "autogenerated id" doesn't remove the requirement for other keys as well. The alternative is not to enforce uniqueness and accept that data will be duplicated and almost inevatibly contain anomalies and lead to errors as a result. Why would you want that?

blocks|key|2979556|text|自然主键是脆弱的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2979557|假设我们已经围绕(CountryCode，PhoneNumber)上的自然PK构建了一个系统，几年后我们需要添加扩展，或者将PK更改为一列:电子邮件。如果将这些主键列传播到所有子表，则开销会非常大。|2979558|几年前，有一些系统是假设社会安全号码是一个自然的PK，当SSN变得不唯一和可为空时，必须重新设计以使用身份。|2979559|因为我们不能预测未来，我们不知道以后的一些变化是否会使过去完全正确和完整的模型过时。|2979560|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Natural primary keys are brittle. 

Suppose we have built a system around a natural PK on (CountryCode, PhoneNumber), and several years down the road we need to add Extension, or change the PK to one column: Email. If these PK columns are propagated to all child tables, this becomes very expensive.

A few years ago there were some systems that were built assuming that Social Security Number is a natural PK, and had to be redesigned to use identities, when the SSN became non-unique and nullable.

Because we cannot predict the future, we don't know if later on some change will render obsolete what used to be a perfectly correct and complete model.

blocks|key|3193126|text|虽然我更喜欢代理键，但在少数情况下我会使用复合用例。复合关键字可以全部或部分由代理关键字字段组成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3193127|3193128|多对多连接表。无论如何，这些通常需要密钥对上的唯一密钥。在某些情况下，键中可能包含其他列。|unordered-list-item|3193129|弱子表。像订单行这样的东西不是独立存在的。在本例中，我在复合表中使用了父表(orders)主键。|3193130|3193131|当存在多个与实体相关的弱表时，可以在查询子数据时从连接集中消除一个表。在孙子表的情况下，可以将祖父母连接到孙子表，而不涉及中间的表。|3193132|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|N|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|P|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

While I prefer surrogate keys, I use composite cases in a few cases. The composite key may consist entirely or partially of surrogate key fields.

<ul>
<li>Many to many join tables. These usually require a unique key on the key pair anyway. In some cases additional columns may be included in the key. </li>
<li>Weak child tables. Things like order lines do not stand on their own. In this case I use the parent (orders) tables primary key in the composite table. </li>
</ul>

When there are multiple weak tables related to an entity, it may be possible to eliminate a table from the join set when querying child data. In the case of grandchild tables, it is possible to join the grandparent to grandchild without involving the table in the middle.

blocks|key|2979703|text|简而言之，组合键的目的是使用数据库来强制执行一个或多个业务规则。换句话说:保护数据的完整性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2979704|例如。您有一份从供应商处购买的零件列表。您可以创建供应商和零件表，如下所示：|2979705|SUPPLIER
SupplierId
SupplierName

PART
PartId
PartName
SupplierId|code-block|syntax|javascript|2979706|啊哦。零件表允许重复数据。由于您使用的是自动生成的代理键，因此您不会强制要求供应商的部件只能输入一次。相反，您应该像这样创建零件表：|2979707|PART
SupplierId
SupplierPartId
PartName|2979708|在此示例中，您的部件来自特定的供应商，并且您希望在部件表中强制执行规则：“单个供应商只能提供单个部件一次”。因此，就有了组合键。组合键可防止意外重复输入零件。|2979709|您可以始终将业务规则留在数据库之外，并将它们留给您的应用程序，但是通过将规则保留在数据库中(通过组合键)，您可以确保业务规则在任何地方都得到执行，特别是在您决定允许多个应用程序访问数据的情况下。|2979710|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

In short, the purpose of composite keys is to use the database to enforce one or more business rules. In other words: protect the integrity of your data.

Ex. You have a list of parts that you buy from suppliers. You could could create your supplier and parts table like such:

<pre><code>SUPPLIER
SupplierId
SupplierName

PART
PartId
PartName
SupplierId
</code></pre>

Uh oh. The parts table allows for duplicate data. Since you used a surrogate key that was autogenerated, you're not enforcing the fact that a part from a supplier should only be entered once. Instead, you should create the PART table like such:

<pre><code>PART
SupplierId
SupplierPartId
PartName
</code></pre>

In this example, your parts come from specific suppliers and you want to enforce the rule: "A single supplier can only supply a single part once" in the PARTS table. Hence, the composite key. Your composite key prevents accidental duplicate entry of a part. 

You can always leave business rules out of your database and leave them to your application, but by keeping the rule in the database (via a composite key), you ensure that the business rule is enforced everywhere, especially if you should ever decide to allow multiple applications to access the data.

blocks|key|2979745|text|正如函数封装了一组指令，或者数据库视图抽象了基表连接一样，代理键也抽象了它们所在实体的含义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2979746|例如，如果您有一个保存车辆数据的表，则应用代理VehicleId将从数据的角度抽象出作为车辆的含义。当你提到VehicleId+=+1时，你肯定是在谈论某种类型的汽车，但我们知道它是一辆2008年的雪佛兰Impala还是一辆1991年的福特F-150？不是的。任何车辆#1的底层数据可以随时更改吗？是。|2979747|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Just as functions encapsulate a set of instructions, or database views abstract base table connections, so to do surrogate keys abstract the meaning of the entity they are placed on. 

If, for example, you have a table that holds vehicle data, applying a surrogate VehicleId abstracts what it means to be a vehicle from a data point of view. When you reference VehicleId = 1, you are most surely talking about a vehicle of some sort, but do we know if it is a 2008 Chevy Impala, or a 1991 Ford F-150? No. Can the underlying data of whatever Vehicle #1 is change at any time? Yes.

blocks|key|2979775|text|简而言之:多列外键自然是指多列主键。仍然可以有一个自动生成的id列作为主键的一部分。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2979776|哲学答案：主键是行的标识。如果有一些信息是行标识的固有部分(比如文章属于哪个客户)。在多客户维基中)-信息应该是主键的一部分。|offset|length|style|BOLD|2979777|一个例子:用于组织LAN聚会的系统|2979778|该系统支持具有相同人员和组织者参加的多个LAN参与方，从而：|2979779|CREATE+TABLE+users+(+users_id+serial+PRIMARY+KEY,+...+);|code-block|syntax|javascript|2979780|有几个方面：|2979781|CREATE+TABLE+parties+(+parties_id+serial+PRIMARY+KEY,+...+);|2979782|但大多数其他内容需要携带关于它链接到哪一方的信息：|2979783|CREATE+TABLE+ticket_types+(
++++ticket_types_id+serial,
++++parties_id+integer+REFERENCES+parties,
++++name+text,
++++....
++++PRIMARY+KEY(ticket_types_id,+parties_id)
);|2979784|...this是因为我们希望引用主键。指向表ticket_types.的表attendances上的外键|2979785|CREATE+TABLE+attendances+(
++++attendances_id+serial,
++++parties_id+integer+REFERENCES+parties,
++++ticket_types_id+integer,
++++PRIMARY+KEY+(attendances_id,+parties_id),
++++FOREIGN+KEY+(ticket_types_id,+parties_id)+REFERENCES+parties
);|2979786|entityMap^0|0|5|4|0|0|0|0|0|0|0|0|E|4|M|C|11|B|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1A|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1C|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|Y|3|Z|5|6|7|1F|8|@$D|1G|E|1H|F|G]|$D|1I|E|1J|F|G]|$D|1K|E|1L|F|G]]|9|@]|A|$]]|$1|10|3|11|5|N|7|1M|8|@]|9|@]|A|$O|P]]|$1|12|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|13|$]]

Short answer: Multi-column foreign keys naturally refer to multi column primary keys. There can still be an autogenerated id column that is part of the primary key.

Philosophical answer: Primary key is the identity of the row. If there there is a bit of information that is an intrinsic part of the identity of the row (such as which customer the article belongs to.. in a multi customer wiki) - The information should be part of the primary key.

An example: System for organizing LAN parties

The system supports several LAN parties with the same people and organizers attending thus:

<pre><code>CREATE TABLE users ( users_id serial PRIMARY KEY, ... );
</code></pre>

And there are several parties:

<pre><code>CREATE TABLE parties ( parties_id serial PRIMARY KEY, ... );
</code></pre>

But most of the other stuff needs to carry the information about which party it is linked to:

<pre><code>CREATE TABLE ticket_types (
 ticket_types_id serial,
 parties_id integer REFERENCES parties,
 name text,
 ....
 PRIMARY KEY(ticket_types_id, parties_id)
);
</code></pre>

...this is because we want to refer to primary keys. Foreign key on table attendances points to table ticket_types.

<pre><code>CREATE TABLE attendances (
 attendances_id serial,
 parties_id integer REFERENCES parties,
 ticket_types_id integer,
 PRIMARY KEY (attendances_id, parties_id),
 FOREIGN KEY (ticket_types_id, parties_id) REFERENCES parties
);
</code></pre>

I'm assigned to migrate a database to a mid-class ERP.
The new system uses composite primary keys here and there, and from a pragmatic point of view, why?

Compared to autogenerated IDs, I can only see negative aspects;

<ul>
<li>Foreign keys becomes blurry</li>
<li>Harder migration or db-redesigns</li>
<li>Inflexible as business change. (My car has no reg.plate..)</li>
<li>Same integrity better achieved with constraints.</li>
</ul>

It's falling back to the design concept of candiate keys, which I neither see the point of.

Is it a habit/artifact from the floppy-days (minimizing space/indexes), or am I missing something?

//edit//
Just found good SO-post: <a href="https://stackoverflow.com/questions/159087/composite-primary-keys-versus-unique-object-id-field">Composite primary keys versus unique object ID field</a>
//

Why are composite primary keys still around?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的任务是将一个数据库迁移到一个中级ERP。新系统到处使用复合主键，从实用的角度来看，为什么？与自动生成的I相比，我只能看到负面的方面；随着业务的变化，外键在Harder或db-redesignsInflexible时变得模糊。(我的车没有通过约束更好地实现reg.plate..)Same完整性。它退回到候选键的设计概...

问为什么复合主键仍然存在？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么复合主键仍然存在？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么复合主键仍然存在？
EN