对以下系统使用数据库轮询或事件更好吗?

我正在开发一个订购系统,它的工作方式与netflix的服务工作方式完全相同(如果您不熟悉netflix,请参阅本问题的末尾)。我有两种方法,我不确定哪种方法是正确的;一种依赖于数据库轮询,另一种是事件驱动的。

以下两种方法假定此简化模式:

member(id, planId)
plan(id, moviesPerMonthLimit, moviesAtHomeLimit)
wishlist(memberId, movieId, rank, shippedOn, returnedOn)

轮询 :我将在wishlist中运行以下计数查询

1. count movies shippedThisMonth(其中shippedon不为空@memberID)
2. moviesathome计数(其中shippedon不为空,returnedon为空@memberid)
3. moviesinlist计数(@memberid)

以下函数将确定要传送的电影数量:

moviesToShip = Min(moviesPerMonthLimit - shippedThisMonth, moviesAtHomeLimit - moviesAtHome, moviesInList)

我将遍历每个成员,运行计数,并遍历它们的列表,次数与moviesToShip相同看起来像是脖子痛,但很管用。

事件驱动: 这种方法包括添加一个额外的列“queuedforshipping”,并在每次事件发生时将其标记为0,1。我将进行以下计数:

1. count movies shippedThisMonth(其中shippedon不为空@memberID)
2. moviesathome计数(其中shippedon不为空,returnedon为空@memberid)
3. 计数moviesQueuedForShipping(其中QueuedForShipping=1,@memberID)

不使用min,我必须使用以下if语句

If moviesPerMonthLimit > (shippedThisMonth + moviesQueuedForShipping)
AND IF moviesAtHomeLimit > (moviesAtHome + moviesQueuedForShipping))

如果这两个条件都为真,我将从queuedForShippinh=0的wishlist中选择一行,并将其设置为queuedForShipping为1每当有人添加、删除、重新排序列表时,我都会运行此函数。到了发货的时候,我会选择@memberId where queuedForShipping=1在更新shippedAt和returnedAt时,我也会运行这个。

方法一很简单。它还允许成员们在有人决定进行投票之前乱搞自己的队伍那样的话,什么船总是由等级决定的。但ppl一直在说投票是不好的。

事件驱动的方法是自我维持的,但是每次一个人更改列表时,用所有这些计数ping数据库似乎是浪费时间。我还要给queuedForShipment列写信这也意味着当一个成员重新排列他们的列表并且他们有挂起的装运(shippedat为空,queuedforshipping=1)时,我将不得不更新这些行并基于新的列组将queuedforshipping设置回1。(如果有人加了5部电影,然后突然去改变顺序怎么办?好吧,在他或她添加的前两部电影中,queuedforshipment已经设置为1)

有人能告诉我他们对这里最好的方法的看法,以及投票相对于事件驱动的缺点/优势吗?

Netflix是一项每月订阅服务,您可以在其中创建一个电影列表,并根据您的服务计划限制将电影发送给您。