2014-01-05 19 views
1

所以我的想法是讓用戶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-TableFeedback-Table

在短:應該是非常相似的CouchSurfing。例如。留在家裏是一種安排,主人和客人可以離開一個反饋給另一個。

對此設置有什麼想法?它是好還是壞?我怎樣才能讓它變得更好?

enter image description here

回答

2

聽起來合理,但你的設計極限A和B僅具有一個裝置,其具有作爲請求者和B作爲受體。

生成一個int值作爲PK的使用(以及反饋中的FK),你就在那裏。

+0

感謝您的支持:P但是您的描述問題是否仍然有效,因爲我將接受者和請求者的ID傳遞給了安排?因爲用戶A可以多次成爲接受者。有了這個,他僅限於一次與用戶B一起安排SAME安排。意思是:用戶A和B不能在相同的安排中多次「見面」。 – JustBasti

+0

另一個:我只注意到它的廢話拉動反饋和FeedbackMessages分開。 :P – JustBasti

+1

我#m不確定。你的圖表顯示,並且你說,「它的主鍵由用戶A和B的ID構成」。如果A + B是其獨特的PK。不過,如果你知道這一點,並沒有真正做到這一點,那很好。 –