在这种情况下，模型之间需要什么关联？
我正在使用 Rails 制作一个预订系统。
我有 3 个模型 - 访客、房间和预订。
游客可以住在房间里。
一次预订可以有许多访客并位于许多房间（或共享）。预订还有开始/结束日期。
访客可能会在预订中的房间之间移动，并且需要知道这些房间分配的开始/结束日期。
这里单个连接表就足够了吗？即visitor_id、room_id、booking_id？
或者这些模型之间的关联如何？我需要额外的桌子吗，即房间分配。
非常感谢。
I am making a booking system using rails.
I have 3 models - visitors, rooms and bookings.
Visitors can stay in rooms.
A booking can have many visitors and be in many rooms (or shared). A booking also has a start/end date.
Visitors could potentially move between rooms within a booking, and the start/end dates of these room allocations would need to be known.
Would a single join table suffice here? I.e. visitor_id, room_id, booking_id?
Or how would the associations between these models look? Would I need additional tables i.e. room allocation.
Thank you very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为你应该有 room_allocations 表。
I think you should have room_allocations table.
如果访客更换房间，是否可以创建新的预订？在这种情况下，您不需要额外的表。
Is it possible to create new booking if the visitor change the room? In this case you don't need the additional table.
目前尚不清楚“或共享”是什么意思。
否则，一般过程是列出您的实体，然后定义它们之间的关系。它会是这样的 - 我并不是想在这里给出明确的答案，而是为了说明如何思考它：
实体
首先尝试定义您的属性并将它们分组为实体。制作数据字典很好，特别是在团队合作时。
关系
尽量具体 - 与为关系命名相比，说预订可以拥有许多访客的帮助要小一些（语义对于系统设计）。
说由访客进行的预订/访客进行了预订更好，因为它可以让您区分与名称的关系：预订是为访客/访客进行的预订（并且还可以帮助您意识到是否两者都具备并有助于确定基数；以两种方式命名它们也可以有所帮助，尽管有时您最终会使用尴尬的语言 - 这可能会也可能不会表明设计问题；对于这里的例子访客预订了听起来很糟糕，让我怀疑预订本身是否不是一个关系表 - a 弱实体）。
因此，如果您确实列出了所有关系，我们可以更准确地回答您。
注意：拥有三路多对多关系表可以在 中进行非规范化不平凡的方式。规范化非常重要的原因之一不是拥有漂亮的、理想主义的数据库设计，而是能够管理数据库中潜在的不一致（例如，如果您决定采用非规范化设计来了解数据库的异常类型）可以表示；在3NF之前都是相当明显的。
It is not clear what do you mean by 'or shared'.
Otherwise, a general procedure is to list your entities and then define relationships between them. It would go something like this - and I am not trying to give definitive answers here, but to illustrate how thinking about it might go:
Entities
First try to define your attributes and group them into entities. Making a data dictionary is nice, especially if working in teams.
Relationships
Try to be specific - saying that booking can have many visitors is less helpful compared to giving the relationship a name (semantics is very important in system design).
Saying booking made by visitor(s)/visitor(s) booked a booking is better, because you it allows you to distinguish between a relationship with a name: booking is made for visitors/visitors booked (and also helps you realise if you have both and helps determine cardinality; naming them in both ways also can help, although sometimes you end up with awkward language - which might or might not be indication of design problems; for example here visitor(s) booked a booking sounds bad and makes me question if booking is not a relationship table in itself - a weak entity).
So, if you do go and name all the relationships we could answer you much more precisely.
Note: Having a three way many-to-many relationship table can be denormalized in a non-trivial way. And one of the reasons that normalization is very important is not to have beautiful, idealistic database design, but to be able to manage potential inconsistencies in your database (as in - if you decide to have denormalized design to know what kind of anomalies your database could represent; which are fairly obvious up until 3NF).
像这样的东西应该可以帮助您开始：
可能有更简洁的方法来涵盖预订和预订。房间预订。用面向对象的术语来说，您可以使用复合模式对其进行建模。这可能会使逻辑更清晰。当然，您仍然需要映射到表；是否值得探索取决于您的应用程序的更广泛需求。
嗯。
Something like this should get you started:
There are probably neater ways to cover Booking & Room Booking. In OO terms, you could model it using the composite pattern. That would probably make the logic cleaner. You'd still need to map to tables of course; whether it's worth exploring depends on the wider needs of your app.
hth.