我已經看到了不同的表幾種不同的購物車模式爲訂單狀態類型/發貨狀態類型/付款狀態的類型。什麼是購物車'訂購'表的訂單狀態類型的最佳細分？
我希望得到這個權利第一次爲我的項目，不知道最好的方法是什麼，並希望有人與示例表爲我用。
關鍵的事情，當然是，不過多列我用 - 他們必須代表相互排斥的事情。
我想沿着線的東西：
OrderStatus - 摘要狀態 PaymentStatus - 付費/未付/ PartiallyPaid /錯誤 ShippingStatus - 未發貨/ PartiallyShipped /發貨/ DeliveredByHand
最新最好的方式打破這一點 - 我是否應該有一個「總結」狀態，代表整個「人類可讀」狀態以及每個獨立過程的獨立狀態？
任何時候你有一個是「互斥」，這意味着具有該列的多個可能值一列不同的狀態。大多數情況下，這些值應該受到限制，而做到這一點的最好和最常用的方法之一是通過「字典」或「查找」表的外鍵。因此，它是最基本的，你可能有這樣的事情：
OrderStatus將有如值： * 1， 「付費」 * 2 「未付」 * 3， 「出貨」 * 4 「未發貨」
最重要的部分是確定哪些狀態是真相互對其他狀態獨有。例如，我上面的示例行可能不太好，因爲您可能有一個既是「付費」又是「發貨」的訂單。如果是這種情況，那麼你可能會將OrderStatus分成PaymentStatus和ShippingStatus（如你所暗示的那樣）。
確定是否拆分這些行取決於您和您的具體需求。然而，無論你決定，假設你將不得不改變它在某個時刻。通常情況下，永遠不會改變的唯一應用程序/數據庫是因爲缺乏使用而被放棄的失敗的。 「第一次做對」是一個令人敬佩的目標，提前做好研究是值得的，但你幾乎可以肯定不是實現它。相反，花你的精力使你的設計/代碼的其餘部分靈活變化，以便你可以重新制作其中的一部分而不必撕毀整個應用程序。
這真的，真的取決於車本身的全部功能。我會建議遵循SDLC，這會讓您更好地瞭解您需要開始什麼功能，從而更清楚地瞭解您需要在數據庫中存儲哪些數據（表/字段）。
這裏有一些鏈接，讓你開始與：
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
一旦你的開始，通常可以決定哪些字段和值，你需要爲你的進步。
一旦你確定哪些存儲在數據庫中的數據需求的時候，你可以使用數據庫規範化指導幫助構建你的表
http://en.wikipedia.org/wiki/Database_normalization
希望幫助！
「假設我將不得不改變它」的額外功勞！ –
是的，這可能是最重要的部分。這句話曾經是「建立一個扔掉」;這些日子更多的是關於短的開發週期，重構和客戶反饋，但這個想法是一樣的。單片式的前端設計方法顯示效果不佳。 –