哪种MySQL架构最适合此类系统

Question

假设一个类似于Netflix的系统，其成员创建电影愿望清单，并根据他们的计划类型，其列表中的一部，两部或更多部电影转为订单，以下其中一个模式制作更多感？

1. 存储以下列的控制表：

   控件（memberid，currentMoviesAtHome，moviesAtHomeLimit，currentMonthlyMovies，monthlyMoviesLimit）

用户实际上并不决定何时创建订单，因为这取决于他们的帐户控制。日常功能将通过客户及其控件，并选择currentMoviesAtHome < moviesAtHomeLimit AND currentMonthlyMovies < monthlyMoviesLimit ...

1. 链接到accounts计划表的单独plans表：

   帐户（memberid，planid，currentMoviesAtHome，currentMonthlyMovies）

   计划（planid，moviesAtHomeLimit，monthlyMoviesLimit）

Answer 1

具有ACCOUNTS和PLANS表格的第二个选项已经标准化，因此这将是我的建议。

此外，这些表格：

• MOVIES
• WISHLIST
  • movie_id（主键，MOVIES.movie_id的外键）
  • account_id（主键，ACCOUNTS.account_id的外键）
  • is_onsite

is_onsite将是一个布尔值，用于确定电影是否已发送到客户端。如果有，则应将值设置为1.使用此值来汇总以了解帐户是否处于或低于其计划限制。返回视频时，仅删除is_onsite设置为1的行。

Answer 2

  

日常功能将通过客户及其控件并选择

这不能回答你的问题，但我想我会提到你的设计不是最理想的。如上所述，您可以更好地决定按需进行操作，而不是轮询;也就是说，您的应用程序中显然会有一段时间来更新限制值。你应该做的是当时发生某种事件并消耗决定是否发送另一部电影的事件。

每日轮询不会扩展。

点击和处理事件不仅会更快，而且从长远来看也会更容易维护。祝你好运。