哪種MySQL架構最適合這種類型的系統

假設一個類似於Netflix的系統，其中成員創建電影的願望清單，並且根據他們的計劃類型，列表中的一個，兩個或更多個電影進入訂單，下列哪種模式更有意義？哪種MySQL架構最適合這種類型的系統

A控制表中存儲下列：

對照（MEMBERID，currentMoviesAtHome，moviesAtHomeLimit，currentMonthlyMovies，monthlyMoviesLimit）

當訂單爲創建的用戶實際上並沒有決定這取決於他們的賬戶控制。每日函數將通過客戶和他們的控制和選擇的人在那裏currentMoviesAtHome < moviesAtHomeLimit AND currentMonthlyMovies < monthlyMoviesLimit ...

單獨accounts錶鏈接到plans計劃表：

賬戶（ MEMBERID，planid，currentMoviesAtHome，currentMonthlyMovies）

計劃（planid，moviesAtHomeLimit，monthlyMoviesLimit）

來源

2010-09-13 Mohamad

難道你沒有另一張表格列出用戶擁有的電影，包括上個月返回的電影嗎？難道你不希望'在那張表上選擇COUNT（*）WHERE ...'來確定'currentMoviesAtHome'和'currentMonthlyMovies'，而不是存儲可能不同步的單獨值嗎？ – 2010-09-13 04:34:19

第二個選項，ACCOUNTS和PLANS表格被標準化，所以這將是我的建議。

另外，這些表中：

MOVIES
WISHLIST
- movie_id（主鍵，外鍵MOVIES.movie_id）
- ACCOUNT_ID（主鍵，外鍵ACCOUNTS.account_id）
- is_onsite

is_onsite將是一個布爾值，以確定電影是否已發送到客戶端。如果有，則應該將值設置爲1.使用此值來計算帳戶處於或低於其計劃限制的總和。當返回視頻，只能刪除已is_onsite設置爲1

來源

2010-09-13 04:06:25

行每日函數將通過客戶和他們的控制和選擇

這不回答你的問題，但我我想我會提到你的設計是不理想的。正如你上面描述的那樣，而不是輪詢，你決定按需做什麼更好;也就是說，在應用程序的使用中顯然會有一段時間限制值將被更新。你應該做的是在那個時候發起一些事件，並且消費會決定是否發送另一部電影的事件。

每天投票不會縮放。

發射和處理事件不僅會更快，而且從長遠來看，維護起來會更容易。祝你好運。

來源

2010-09-13 04:26:22 RibaldEddie

另一種方法是在電影/項目返回時運行邏輯。當這種情況每天可以進行一次輪詢時，輪詢聽起來並不是那麼糟糕，因爲在一天之內，物品不可能被退回並郵寄給下一位客戶。這很合理，但作爲一個服務提供商，你需要一個小小的迴旋空間。 – 2010-09-13 04:30:30

@ Ribald，使用這種方法意味着我必須檢查每次用戶是否更改他的願望清單/添加刪除項目......如果用戶已經有最大的訂單，這不會浪費資源嗎？如果我們應該在人員超出限額時創建訂單，或者已經打開兩個訂單，有什麼用途？ – Mohamad 2010-09-13 05:06:49

您不需要重新檢查用戶何時向願望清單中添加或刪除項目，因爲修改該信息不會更改他們簽出的電影數量的值。 OMG Ponies是正確的，你只需要檢查什麼時候你要修改有問題的值;即，當電影被返回時。 – RibaldEddie 2010-09-13 05:32:29

哪種MySQL架構最適合這種類型的系統

回答

相關問題