关联 2 个或更多关系表的最佳实践是什么？
我有一个旅行（主要：idTrip），我可以在其中链接更多包（主要：idPackage），因此，我有一个关系表来链接旅行与包（主要：idRelTripPackage）。 （n对n关系）
接下来我得到了一个注册表（主要：idRegistration）。我如何最好地链接这些（一对一关系）？
- 我在注册表中添加两列（idTrip、idPackage）？
- 我添加一个关系表，在其中链接 idRegistration、idTrip、idPackage？
- 我添加一个关系表，在其中链接 idRegistration、idRelTripPackage？
I have a trip (primary: idTrip), where I can link more packages (primary: idPackage), so, I got a relationship table to link trips with packages (primary: idRelTripPackage). (relationship n-to-n)
And next I got a registrations table (primary: idRegistration). How do I best link those (1-to-1 relationship)?
- I add two columns in the registrations table (idTrip, idPackage)?
- I add a relationship table where i link idRegistration, idTrip, idPackage?
- I add a relationship table where i link idRegistration, idRelTripPackage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我是否正确地认为注册与 RelTripPackage 之间的关系是正确的，而且它绝对是一对一的。有几个选项：
1：因为它确实是一对一的，所以没有什么可以阻止您将注册数据直接放入 RelTripPackage，或者反之亦然，将 idPackage 和 idTrip 直接作为 FK 放入注册中，在两个 FK 列之间使用唯一键以确保不存在重复项。
2：如果确实需要两个单独的表，则只需将 idRetTripPackage 作为 FK 添加到 Registrations 中，然后在其上添加唯一约束 - 再次确保唯一性。
不需要单独的关系表，因为它是 1-1 关系 - 它们只有在您使用 nn 时才真正变得相关。其余时间FK应该直接放在子表上。
Am I right in thinking the relation from Registrations is to RelTripPackage, and its definitely one-to-one. There are a couple of options:
1: As it really is a one-to-one there's not really anything to stop you putting the Registrations data directly onto RelTripPackage, or doing the vice-versa and putting idPackage and idTrip straight onto Registrations as FKs, with a unique key across the two FK columns to ensure there aren't duplicates.
2: If do want the two separate tables then just add idRetTripPackage to Registrations as an FK, and then add a unique constraint on it - again to ensure uniqueness.
There's no need for a separate relationship table as its a 1-1 relationship - They only really become relevant when you are using an n-n. The rest of the time FKs should be placed directly on the child table.
如果遵循该逻辑，则
但是问题（限制因素）是您开始使用的表是实际上并未标准化。由于起始位置没有良好的基础，因此您最终会得到比实体之间实际关系多得多的关系（在表中）。因此，最好的建议是，最佳实践是，在尝试当前的扩展之前，退一步并规范化数据和现有表。那么扩展就会容易得多，并且最终会得到更少的表。
一般来说，任何与实体的 PK 为 1::1 的属性都应该是该实体中的属性。任何与实体的 PK 为 1::0-1 的属性都应位于单独的表中。
ER 图
根据所提供的信息，这是您的 ▶实体关系图◀。只要您使用关系标识符，则直接支持您迄今为止识别的所有关系（否则，如果您使用ID，则将需要更多关系和表）。
不熟悉关系数据库建模标准的读者可能会发现 ▶IDEF1X 表示法◀很有用。
If you follow that logic, you will
However the problem (limiting factor) is that the tables you are starting with are not actually normalised. Since the starting position does not have a good basis, you will end up with far more Relations (in tables) than there actually are between the Entities. So the best advice is, the Best practice is, before you attempt this current extension, step back and normalise the data, the existing tables. Then the extension will be much easier, and you will end up with less tables.
Generally any attribute that is 1::1 with the PK of an Entity should be an attribute in that entity. Any attribute that is 1::0-1 with the PK of an Entity should be in a separate table.
ER Diagram
Based on the information provided, this is your ▶Entity Relation Diagram◀. As long as you use Relational Identifiers, all the Relations you have identified thus far are supported directly (otherwise, if you use IDs, you will need more Relations and tables).
Readers who are unfamiliar with the Relational Database Modelling standard may find ▶IDEF1X Notation◀ useful.