Rails：CouchSurfing-Like数据库结构

所以我的想法是让用户A请求来自另一用户B的任意数量的安排（任何服务）。用户A和B都可以将反馈留给每个用户B和A（只有一个每个用户和服务）。 就像CouchSurfingRails：CouchSurfing-Like数据库结构

我对数据库和Ruby on Rails上设置的一些想法，但会很高兴，如果你会对它快速浏览一下，因为我仍然在寻求对知识的初学者。

让我们来示例场景：

但首先快速的注意：重要的是，每个用户都成为承兑人或者请求的能力。

用户A从另一个用户B请求该服务（在这种情况下，用户A变为Requestor，用户B变为Acceptor，他需要接受用户A的请求）。一旦用户B接受了请求，就构建了一个Arragement，其主键由用户A和B的ID构成。在该排列表中有几个与排列有关的信息。一旦安排发生了，用户A和B被允许给feedback其他用户（但只有一个！）

这就是为什么我已经设置了单独的表为受体，请求者和安排。我想控制用户可以通过数据库方式提供多少次反馈。

现在每个用户都有（肯定）一个用户展示页面，其中显示了他收到的所有反馈。意思是：每个用户都有N个反馈（或者消息，如果你以数据库的方式看到它的话）。这就是为什么我提取的Message-Table出Feedback-Table

在短：应该是非常相似的CouchSurfing。例如。留在家里是一种安排，主人和客人可以离开一个反馈给另一个。

对此设置有什么想法？它是好还是坏？我怎样才能让它变得更好？

enter image description here

来源

2014-01-05 JustBasti

听起来合理，但你的设计极限A和B仅具有一个装置，其具有作为请求者和B作为受体。

生成一个int值作为PK的使用（以及反馈中的FK），你就在那里。

来源

2014-01-07 11:23:59

感谢您的支持：P但是您的描述问题是否仍然有效，因为我将接受者和请求者的ID传递给了安排？因为用户A可以多次成为接受者。有了这个，他仅限于一次与用户B一起安排SAME安排。意思是：用户A和B不能在相同的安排中多次“见面”。 – JustBasti

另一个：我只注意到它的废话拉动反馈和FeedbackMessages分开。：P – JustBasti

我＃m不确定。你的图表显示，并且你说，“它的主键由用户A和B的ID构成”。如果A + B是其独特的PK。不过，如果你知道这一点，并没有真正做到这一点，那很好。 –

Rails：CouchSurfing-Like数据库结构

回答

相关问题