2012-02-23 58 views
1

我將很快提供一些基於Web的服務,並且我正在開發訂閱系統。用戶每月支付(或者可以提前幾個月支付),但我提供不同的軟件包。不同的軟件包允許他們每天使用系統x分鐘。訂閱套餐並存儲它們

因此,例如

包一個讓他們使用它一天
套餐二讓他們使用它一天
套餐三讓他們使用它一天

10分鐘5分鐘2分鐘

等等。這些都是每月。

我現在的方法可以讓我設置他們的包和他們的訂閱何時結束。我想改變它,以便他們可以有多個包。

我的問題是這樣的:

他們買一包。他們使用它兩天,並決定他們想升級到另一個軟件包。他們購買第二包。現在他們有2個月的時間(減去兩天),但是它將包裝二。從本質上來說,他們僅僅爲套餐一的價格獲得了兩個月的套餐。

所以我的想法是這樣的:

我可以單獨存儲每一筆交易,並在當包結束設定每筆交易和封裝它。然後我可以SELECT `package` FROM `packages` WHERE `status`='active????' ORDER BY `package` DESC LIMIT 1;這將允許我選擇他們的高級包,並給他們,直到那個變得不活動,然後恢復到較小的包。問題是這個`status`='active'沒有跟蹤日期。我怎樣才能正確地做到這一點?

回答

0

我曾與「每分鐘付費」的交易,這是一個恐怖的故事。至少我提出的場景是因爲客戶端時間和服務器端可以是兩個不同的世界(例如暫停加載的流式視頻與用戶在頁面上的日期差異決定的實際時間)。

這是我們如何處理它 - 除了平衡打嗝補償 - 用戶購買分鐘簡單明瞭。如果他們升級,他們將根據他們在購買新的分鐘後收取的價格按比例分攤未使用的分鐘數。這樣,如果在退款發生後收費時出現問題,您不會失利。 退款不是文字交易。它會轉儲到與用戶相關的餘額中,然後按比例分攤的金額降低升級價格。將付費分鐘數恢復爲零 - 在添加新的升級分鐘數之前。

系統中的漏洞通過將每個「單元」減少到最低的形式並將經濟基於該數字而解決。所以沒有「包裝」可言。根據購買用戶的時間,用戶數量和每分鐘成本只有幾分鐘。這樣,如果您的費率發生變化,則不會影響可能預付多年的舊用戶。

請注意,這是一個簡化的例子。實際的系統非常複雜。

對於您的情況,每日限制只是一個關係表,它可以在單個負載的基礎上存儲日期和集體頁面時間,但是您選擇確定該時間。沒有一個試圖積累的條目,但是您可以收集儘可能小的個人條目,並儘可能地將它們彙總。如果有人抱怨說他們的電腦凍結了,並且他們的時間超出了他們的控制範圍,這將爲您節省大量時間。 因此,當您的總和腳本檢測到分鐘已達到或超過他們目前的限制,它只是拒絕訪問。

0

你應該只有一個包。升級時應減去新舊包裝中使用的分鐘數。只要保留舊的包是歷史記錄。