2016-03-27 150 views
1

我應該使用azure爲REST服務組織消息傳遞。現在我遇到了數據庫問題。我有3個表格:用戶,聊天,聊天消息。Azure表中的表格設計存儲

  1. 用戶包含用戶數據,如登錄,密碼哈希,鹽。
  2. 交談包含partitionkey - userlogin,rowkey - chatId,nowInChat - 用戶來自聊天。聊天的
  3. 消息包含partitionkey,至極由 userlogin_chatId_datetimeticks (zevis_8a70ff8d-c363-4eb4-8a51-f853fa113fa8 _634292263478068039) rowkey - MESSAGEID,消息發送者 - 用戶登陸。

我看到了設計中的缺點,例如,如果你想象用戶在一年前積極溝通,現在不說話,其中一個人想看歷史,那麼我會有以一定的時間間隔(例如一週)向服務器發送大量請求,請求數據。發送請求的時間少於今天將無效,因爲我們掌握了整個故事。 我們應該如何改變表格的設計?

+0

我認爲你需要更加規範化你的數據;這通常在NoSQL鍵值數據庫中完成,以解決這樣的問題。 –

回答

0

感謝您的留言,您有兩種選擇。用最少的設計更改最容易的答案是在聊天表中包含StartTime和EndTime。雖然這些屬性不會被編入索引,但我猜測在篩選UserID後不會有很多行要掃描。

第二個選項需要更多的工作,但清潔劑,將創建一個分區鍵=用戶名的附加表,行鍵= DateTimeTicks和你的實體屬性將包含ChatID。這將使您能夠在給定的日期/日期範圍內快速過濾用戶。 (這是上面提供的非規範化答案)。

希望這有助於您的設計進度。

0

我將創建一個單獨的表與這些PK和RK值: 分區鍵=用戶名,行鍵= DateTime.Max - DateTimeTicks

您也可以選擇追加ChatId上述行鍵結束。

這樣用戶所做的最新通信將始終在最前面。所以你稍後可以通過僅傳入UserId和一個計數來簡單地查詢表(即如果你想從用戶那裏獲得最新的聊天記錄,取計數= 1)。查詢速度也會非常快,因爲由於您使用的是反轉行號作爲行鍵,因此天青表存儲服務會按增加行鍵的字典順序對相同用戶標識的條目進行排序,並始終將最新的聊天記錄保留在分區頂部它將具有最小反轉刻度值。

即使您在RowKey的末尾添加了聊天ID(即InvertedTicks_ChatId),排序順序也不會改變,並且無論聊天ID如何,最新的對話都將位於最前面。

一旦你讀完了實體,你就從DateTime.Max中減去倒置的滴答來找到實際的日期。