【问题标题】:What type of logic does Netflix use to create customer orders?Netflix 使用什么类型的逻辑来创建客户订单?
【发布时间】:2010-09-20 12:33:39
【问题描述】:

我想实现类似的东西,但我遇到了一些问题。我想知道解决这个问题的选择是什么,以及在这种情况下使用的常用技术是什么。 (如果您不熟悉 Netflix,请参阅此问题的底部)

目前的方法 创建一个“控制”表,其中包含有关客户状态的信息并将其交叉引用到服务计划表。

controls(member_id, movies_rented_this_month, movies_at_home)
plans(movies_per_month_limit, movies_at_home_limit)

当商品被退回时,请检查控制表以查看客户是否有资格接收另一个订单。

if controls.movies_at_home < plan.movies_at_home_limit
and if controls.movies_this_month < plan.movies_this_month_limit

对于之前没有订单的任何人(新客户),或者在关闭订单时他们的电影队列中没有任何内容的人,我们会创建一个预定事件来创建订单(轮询)。

问题我们需要考虑每个客户可以根据他们的计划获得多少订单。上述逻辑在某些情况下会失败:

plans.movies_this_month_limit = 4, controls.movies_this_month = 3
plans.movies_at_home_limit = 2 , controls.movies_at_home = 0

在上述情况下,有资格获得一份订单的客户将收到两份。颠倒标准可以逆转问题。

简化架构

members(id, plan_id)
movies(id, title)
plans(id, movies_at_home_limit, movies_per_month_limit)
controls(member_id, movies_at_home, movies_this_month)
movie_queue(member_id, movies_id)

Netflix 允许会员保留电影愿望清单的在线电影租赁服务。客户会根据他们的计划类型从他们的愿望清单(通过邮件)逐步接收电影。

【问题讨论】:

  • > 暗示我们对封闭系统一无所知
  • 我已经添加了一个简短的解释 Netflix 是什么以及我的架构是什么。抱歉,其中一件事让我措手不及。

标签: database-design


【解决方案1】:

我怀疑它不使用 CONTROLS 表,而是检查其内部运输/接收历史,以便在确定是否向客户运送电影时即时确定任何客户拥有多少部电影。

考虑到发货/收货历史表中单个客户 ID 的高选择性,探查 (MEMBER_ID, SHIP_DATE, DISC_ID)(MEMBER_ID, RECEIVED_DATE, DISC_ID) 上的假设索引以回答 CONTROLS 表寻求的问题并不昂贵。


CONTROLS 不是表格;这是一个视图/标量子查询。给定成员 ID 和日期,并为清楚起见假设 SHIPPED_DISK 和 RECEIVED_DISK 是单独的表:

movies_rented_this_month = (SELECT COUNT(*) FROM SHIPPED_DISC 
                             WHERE MEMBER_ID = :member_id
                               AND SHIP_DATE >= FIRST_DAY_OF_MONTH (:date)
                               AND SHIP_DATE <  FIRST_DAY_OF_MONTH (:date) + 1 month)

movies_at_home = (SELECT COUNT(*) FROM SHIPPED_DISC shp
                   WHERE MEMBER_ID = :member_id
                     AND NOT EXISTS (SELECT NULL FROM RECEIVED_DISC rcv
                                      WHERE shp.member_id = rcv.member_id
                                        AND shp.disc_id   = rcv.disc_id)

或许

       (SELECT ship_count - receive_count 
          FROM (SELECT COUNT(*) ship_count FROM SHIPPED_DISC shp
                 WHERE MEMBER_ID = :member_id
                UNION ALL
                SELECT COUNT(*) receive_count FROM RECEIVED_DISC rcv
                 WHERE MEMBER_ID = :member_id) dummy
        )

或者,您可以维护一个 MEMBER_HAS_DISC 表(我再次假设是光盘,但对于 Netflix,也有流媒体,因此可能需要将其抽象为 MEMBER_HAS_PRODUCT),其中运输/接收日志插入到从该表中删除,并且很容易检查。我认为了解客户拥有什么比他们使用了多少代币更有用。

【讨论】:

  • Adam,您的意思是发货/收货表可以处理生成订单的逻辑,而不是使用控件的表?你能给我一个简短的例子来说明它是如何起作用的吗?我不是指代码,而是对所涉及的逻辑的概述......
  • 谢谢亚当。我知道它是如何工作的。但是,如果我们在 shipping 表中添加一个 shipping_returned_on 列并避免将退货表放在一起,那不是更简单吗?
  • 也许吧。这取决于数据量。我可以说,在 Oracle 和 DB2 中,更新表比插入记录要昂贵得多。如果它们是独立的事件,也许应该这样建模。
猜你喜欢
  • 2021-04-25
  • 1970-01-01
  • 1970-01-01
  • 2017-10-08
  • 2016-12-25
  • 2021-12-10
  • 2018-10-02
  • 2022-05-03
  • 1970-01-01
相关资源
最近更新 更多