我正在使用rails制作预订系统。在这种情况下模型之间需要什么关联？
我有3个模特 - 访客，房间和预订。
访客可以留在房间里。
预订可以有许多访客，并在许多房间（或共享）。预订还有一个开始/结束日期。
访客可能会在预订内的房间之间移动，这些房间分配的开始/结束日期需要知道。
这里只有一个连接表就够了吗？即visitor_id，room_id，booking_id？
或者这些模型之间的关联会如何看待？我是否需要额外的表格，即房间分配？
非常感谢。
我想你应该有room_allocations表。
游客可能会室之间的预订中移动 和 这些房间 分配将需要知道的开始/结束日期。
如果访客更换房间，是否可以创建新预订？在这种情况下，您不需要额外的表格。
我希望所有的细节都能成为一个预订的一部分，而不是每次访客转移房间时创建新的预订。我在想房间分配表是最合适的。不管怎么说，还是要谢谢你。 – user88 2010-11-24 12:44:58
预订可以有许多访问者和 在许多房间（或共享）。 A 预订还有一个开始/结束日期。
目前尚不清楚“'或'共享'是什么意思。
否则，一般程序是列出您的实体，然后定义它们之间的关系。它会去这样的事情 - 我不是想在这里给出确切的答案，但要说明如何思考它可能会去：
实体
首先尝试定义您的属性，并将它们组合成实体。制作数据字典非常好，特别是在团队中工作时。
关系
尽量具体 - 说，预订可以有许多游客较少有益相比给人的关系的名称（语义是在系统设计中非常重要）。
话说预订的访客（县）/访客（县）提出过预订的预订是更好的，因为你它可以让你使用一个名称的关系区分：预订为游客制作/人次预订（也有助于你意识到，如果你有两个并且有助于确定基数;以两种方式命名它们也可以提供帮助，尽管有时你最终会遇到尴尬的语言 - 这可能或可能不是设计问题的指示;例如这里visitor ）预订了一个预订听起来不好，让我质疑，如果预订本身不是一个关系表 - 一个weak entity）。
所以，如果你确实去了并命名所有的关系，我们可以更准确地回答你。
注意：有一个三路多对多关系表可以在non-trivial way非规范化。规范化非常重要的原因之一是不要有美观，理想的数据库设计，而是要能够管理数据库中潜在的不一致性（如果您决定让非规范化设计知道数据库的异常情况可以表示;直到3NF），这是相当明显的。
像这样的东西应该让你开始：
可能有更简洁的方式来支付预订&室预订。按照OO术语，您可以使用复合模式对其进行建模。这可能会使逻辑更清洁。当然，你仍然需要映射到表格。是否值得探索取决于您的应用程序的更广泛的需求。
hth。
我认为这可能是一种方式，以及一个room_allocation_visitors表。谢谢。 – user88 2010-11-24 12:46:04