Netflix用什麼類型的邏輯來創建客戶訂單？

我想實現類似的東西，但我遇到了一些問題。我想知道我的選擇是什麼解決這個問題，以及在這種情況下使用的常用技術是什麼。（見這個問題的底部，如果您不熟悉與Netflix）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的 在線電影租賃服務，允許會員，以保持電影的心願。客戶根據他們的計劃類型逐漸從他們的願望清單（通過郵件）收到電影。

來源

2010-09-20 Mohamad

>暗示我們知道有關封閉系統的任何信息 – 2010-09-20 12:34:58

我已經添加了關於Netflix的簡要說明以及我的模式是什麼。對不起，其中一件事引起了我的警惕。 – Mohamad 2010-09-20 12:42:19

我懷疑它不使用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），其中發送/接收日誌插入到該表中並從中刪除，並且很容易檢查。我認爲知道客戶的用途比他們使用多少令牌更有用。

來源

2010-09-20 15:45:06

亞當，你在說什麼是運輸/接收表可以處理產生訂單的邏輯而不是使用控制表？你能否給我一個簡單的例子來說明這可能如何運作？我不是指代碼，而是對所涉邏輯的概述...... – Mohamad 2010-09-20 16:05:12

請參閱編輯答案，因爲它太過參與評論。 – 2010-09-20 20:31:00

謝謝Adam。我看到它是如何工作的。但是，如果我們在發貨表中添加了shipment_returned_on列並避免了一起使用退貨表，那會不會更簡單？ – Mohamad 2010-09-21 13:34:25

Netflix用什麼類型的邏輯來創建客戶訂單？

回答

相關問題