blocks|key|4499877|text|多对多关系只是一个具有2个一对多关系的表，可以将其视为具有2个关系的3个表，而不是具有关系和与之关联的数据的2个表。在实现上没有区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4499878|无论哪种方式，这都是完全可以接受的。|4499879|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|$]]

A many to many relationship is simply a table with 2 one to many relationships, think of it as 3 tables with 2 relationships rather than 2 tables with a relationship and data associated with it. There is no difference in the implementation.

Either way it's perfectly acceptable.

blocks|key|1084462|text|除非数据是专门针对该特定关系的，否则应避免这种情况，因为您最终会复制大量数据。在您的示例中，图像链接到类别，因此应该存储在那里。但是，应该在该表中包含指示建立和编辑关系的时间戳，以及创建和修改关系的user-+in。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1084463|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|$]]

Unless the data is specifically for that particular relationship, then avoid this, as you will end up duplicating a lot of data. In your example, the images are linked to the category, and so should be stored there. However, a timestamp indicating when the relationship was made and edited, as well as user-ids that created and modified the relationship, should be in that table.

blocks|key|1084444|text|当然，您可以将此信息存储在那里。在其他任何地方，它都不会被规范化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1084445|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|$]]

Of course you can store this information there. Anywhere else and it wouldn't be normalized.

blocks|key|4500086|text|例如，如果你有一个运动员表和一个比赛表。连接表AthleteRace表示运动员参加该比赛的情况，因此您也可以在其中记录他们的比赛时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4500087|您拥有的两个示例：|4500088|column+-+DiscountForProductsInThisCategory
column+-+CategoryImageForProductsInThisCategory|code-block|syntax|javascript|4500089|属于Category表，因为它们与类别相关，而不是与类别中产品的成员资格相关。|4500090|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

For example, if you have a table of Athletes and a table of Races. The join table AthleteRace represents that athlete's participation in that race, so you could have their race time in there as well.

The two exapmles you have:

<pre><code>column - DiscountForProductsInThisCategory
column - CategoryImageForProductsInThisCategory
</code></pre>

belong in the Category table, as they relate to a Category, not to the membership of a product within a category.

blocks|key|434707|text|这个问题不是要考虑的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|434708|如果是一列，例如。DiscountForProductsInThisCategory是1::1，主键是Category，那么唯一正确的位置就是Category。在ProductCategory中，这将是一个大规模的数据复制。|offset|length|style|CODE|434709|如果一个列是带有关系(ProductId%2BCategoryId)的1::1，那么它的唯一正确位置是ProductCategory。|434710|entityMap^0|0|9|X|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

The question is not the question to be considered.

If a column, eg. <code>DiscountForProductsInThisCategory</code> is 1::1 with the PK of Category, then the only correct place for it is Category. In ProductCategory, it will be a massive duplication of data.

If a column is 1::1 with the relation (ProductId+CategoryId), then the only correct place for it is ProductCategory.

blocks|key|4500052|text|是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4500053|关系可以有属性，IMO。尽管有些设计大师不这么认为。|4500054|考虑一下学生和课程之间的“已注册”关系。如果学生可以注册为学分或审计师，则将此属性存储在关键字为(StudentID，CourseID)的表中将是有意义的。此表是关系表，用于对哪些学生注册哪些课程进行分类。|4500055|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Yes.

A relationship can have attributes, IMO. Although some design masters don't think so.

Consider the "enrolled" relationship between Students and Courses. If a student could be enrolled either for credit or as an auditor, it would make sense for this attribute to be stored in a table whose key is (StudentID, CourseID). This table is the relationship table that catalogues which students are enrolle d in which courses.

blocks|key|1079174|text|我认为将其他字段添加到此表中是完全可以的。我所做的事情的一个例子是，我通常添加一个时间戳字段，这样我就可以知道这两个实体之间的关系是什么时候创建的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1079175|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|$]]

I think it is totally fine to add other fields to this table. One example from things I have done is that I usually add a timestamp field so that I know when the relationship was created between the two entites.

Taking the typical products / categories many-to-many relationship you'd typically have a relationship like follows:

<pre><code>table -- ProductsCategories
column - ProductId
column - CategoryId
</code></pre>

Is it ill advised to add other properties to that relationship, things that only exist on that specific relationship. Such as (please forgive my terrible examples, I'm not good at examples):

<pre><code>table -- ProductsCategories
column - ProductId
column - CategoryId
column - DiscountForProductsInThisCategory
column - CategoryImageForProductsInThisCategory
</code></pre>

Should a many-to-many relationship define anything other than the relationship

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

以典型的产品/类别为例，多对多关系通常如下所示：table -- ProductsCategoriescolumn - ProductIdcolumn - CategoryId将其他属性添加到该关系中是不明智的，这些属性只存在于该特定关系中。例如(请原谅我糟糕的例子，我不擅长举例)：table -- ProductsCategoriescolumn - ProductIdcolumn - Cate

问多对多关系是否应该定义关系以外的任何内容
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多对多关系是否应该定义关系以外的任何内容EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多对多关系是否应该定义关系以外的任何内容
EN