這一般來說，我之前估候購物商城。是有區分上下架日期跟可購買日期。
基本上如果你不想分那麼細的話。是可以只有上下架日期。
上下架日期一般來說是包含了顯示及購買。(我是指我的設計)
而購買日期就是給于購買鍵上是否要出現的條件。
也就是說，在商品的搜尋上會依上下架日期來取得要出現的商品。
但購買鍵則是看可購買日期而定。一般未到購買日期時。購買鍵會出現「即將上市」或是「消售一空」等用語出現。(依日期前或後來判斷)
所以說，依照你的需求的話。其實只要在購買鍵上做一個判斷購買日期就行了。
因為我不確定你是否跟我一樣有規劃上下架日期。要不然其實如果沒顯示的話。也不用太擔心購買的問題了。
你要先分析一下購買權限是什麼，然後再看看是怎樣的操作可以用一個按鈕做到。（也許會需要用不同的方式來控制）
如果要兼顧擴充，也不會衝擊到原有的使用者資料，通常會加兩個table來實做。
只在前端判斷風險太高了，永遠不要相信前端送出來的資料。前端沒顯示不代表資料送不到後端。
整體的建議是先在後端判斷出物品是否過期，render 出過期與否的頁面，然後在購物車/結帳時，利用後端時間去判斷物品是否過期。
正常除了我說的上下架跟購買日期。其實還會有一個商品狀態選項。
我這邊是區分成「待審核」「審核中」「上架」「下架」
(前面兩項是業主的需求，你可以看後面兩項就好」
其名稱雖然跟上下架日期的名稱看起來一樣。其實就是給於區分特殊的控制處理了。
因為再這邊我並不了解你的特性是，還要給會員看到商品?只是不能購買?
這樣一般來說會直接調整購買日期做處理會比較好。
如果是臨時性的。那就只好你在我上面說的狀況多加一個類別。或是另開一個欄位來記錄了。
只是這樣你的購買鍵變成得要多條件判斷就是了。
你寫在結帳的候再判斷一次，因為有可能他老早就加入購物車中只是還沒結帳。
或是寫排程固定時間去將過期的品項移除也是可能；但結帳的判斷一樣不能省那是最後一道防線。
iThome鐵人賽
看影片追技術