blocks|key|2633173|text|你的解决方案是完全可以接受的，我看不出哪里有多余的信息。这是表示多到多关系的正常方法。第三个表称为关系数据库中的连接表。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2633174|entityMap^0|W|3|1K|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

You're solution is perfectly acceptable and I can't see where there is any redundant information. This is the normal way to represent a many to many relationship. Your third table is called a junction table in relational databases.

blocks|key|1076319|text|3起跑表:贡献者、支持者、组织。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1076320|->一个组织有许多贡献者，这意味着如果一个贡献者有一个组织，您只需将一个organization_id设置为贡献者表。如果它可以有许多组织，那么您需要第三个表，比如有organization_contributors+(organization_id，contributor_id)。|1076321|->+--一个组织有许多支持者--与上面的完全相同:)|1076322|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|$]]

3 starting tables: contributors, supporters, organizations.

-> An organization has many contributors means that if a contributor has one organization, you just set an organization_id to the contributors table. If it can have many organizations, you need a third table, say organization_contributors that has (organization_id, contributor_id).

-> An organization has many supporters is exactly the same as above :)

blocks|key|2633220|text|你有典型的MN关系。这是一个组织和贡献者之间的多到多的关系。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2633221|由于数据库引擎通常不支持这种关系，所以需要第三个表。这个联接表将把这个关系缩减为两个1M的关系(一对多)。|2633222|贡献者1:M+ContributorOrganization+M:1组织|2633223|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|$]]

You have a typical MN relationship. That is a many-to-many relationship between organizations and contributors.

Since a database engine does not usually support this kind of relationship, you'll need a third table. This join table will reduce this one relationship into two 1M relationship (one to many).

Contributors 1:M ContributorOrganization M:1 Organization

blocks|key|1076365|text|这被称为多到多的关系，或者你通常如何遇到它:+M:N.没有办法绕过第三个表，虽然它包含冗余信息，但它遵循关系数据库的设计规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1076366|是的，这是有权衡的，但是，当你将一项技术从comfortzone中推出时，这就是你所得到的。如果您希望将冗余保持在最低限度，那么NoSql解决方案可能是值得研究的，但是，这可能会迫使您失去关系数据库管理系统的许多优点。你必须权衡你的选择，并与最适合你的存储设施。|offset|length|1076367|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Nosql^0|0|1S|5|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

This is called a many to many relationship, or how you usually encounter it: M:N. There is no way around the third table, and while it contains redundant information, it follows the design rules of relational databases.

Yes, there are tradeoffs, however that's what you get when you push a technology out of its comfortzone. If you look to keep the redundancy to a minimum, a <a href="http://en.wikipedia.org/wiki/Nosql" rel="nofollow">NoSql</a> solution might be worth looking into, however, this might force you lose a lot of the advantages of an RDBMS. You have to weight your alternatives and go with the storage facility suiting you the most.

I have a set of tables to show the relationship between organziations and supporters below. Although I have done some basic mySQL queries, I know very little about database 'design'. 

I plan to query the database for: 

<ul>
<li>a list of contributors to a specific organization... or, </li>
<li>a list of organizations that a specific supporter supports. </li>
</ul>

The database tables for organiations and contributors may have other columns in the future and receive a lesser amount of queries based on that information. 

<pre><code>A | X 
A | Y 
A | Z 
B | X 
B | Y 
C | X 
C | Z
</code></pre>

How should the tables be set up? I assume that there should be a third table, but there is still redundant information in the third table. Is there a better way of setting up the tables? 

<pre><code>+----+-------+ +-------------+----------+ +----+-------+ 
| id | org | | org | contr | | id | contr.| 
+----+-------+ +-------------+----------+ +----+-------+ 
| 1 | A | | 1 | 1 | | 1 | X | 
| 2 | B | | 1 | 2 | | 2 | Y | 
| 3 | C | | 1 | 3 | | 3 | Z | 
+----+-------+ | 2 | 1 | +----+-------+ 
 | 2 | 2 | 
 | 3 | 1 | 
 | 3 | 3 | 
 +-------------+----------+ 
</code></pre>

Very basic database theory

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

下面我有一套表格来展示组织和支持者之间的关系。虽然我做了一些基本的mySQL查询，但我对数据库‘设计’知之甚少。我计划查询数据库的以下内容：一个特定组织的贡献者名单..。或,一个特定的支持者支持的组织的列表。用于组织和贡献者的数据库表将来可能有其他列，并根据这些信息接收较少数量的查询。A | X  A | Y  A |...

问非常基本的数据库理论
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问非常基本的数据库理论EN