訂閱，單一購買產品和可變服務的數據模型

Question

我正在爲系統設計一個數據庫，該系統將處理基於訂閱的產品，標準的一套折扣價購買產品和可變服務的計費。

客戶可以與多個域相關聯，域可以有多個訂閱，設置定價產品或與之相關的收費變量服務。

我不確定是否將這些類別中的每一個分別放入他們自己的「訂單」表中，或找出解決方案將它們全部編譯到單個訂單表中。

需要某些關於訂閱的信息，例如開始日期或到期日，這與獨立產品無關。可變服務可以是任何價格，因此擁有單個產品表將意味着我將不得不添加一個可能再也不會使用或可能以不同成本的新產品。

什麼是解決這個問題的最好方法，並且將每個分解成單獨的順序表是最好的方法？

Answer 1

與任何數據模型一樣，「最佳」方式取決於您的需求。由於您沒有針對您的特定需求指定很多細節，因此很難說出投注模型是什麼。

但是，一般來說，您需要考慮哪些細節級別是必要的。例如，如果所有訂閱的費用相同並在本月的第一天結算，那麼在您的訂單表中填寫is_subscription ENUM ('Y', 'N')這樣的字段可能就足夠了。如果訂閱的結算日期和價格可能會有所不同，您也需要存儲該信息。在這種情況下，爲訂閱提供單獨的表格可能會更好。

另一個考慮因素就是您的模型中的「訂單」。一種解釋是，訂單包括包含在一個交易中的所有購買，包括一次性購買，可變服務和訂閱。完成的訂單將導致賬單，並且訂閱將在該月的適當日期自動計費，而不會產生新的訂單。

Answer 2

你看過子打字 - 它可能適合你。我的意思是一箇中央「訂單」表，其中包含通用屬性和可選的「是」/特定訂單表的一對一關係。特定的訂單表包含僅針對該類型訂單的特性以及返回到中央訂單表的外鍵。

這是試圖獲得最好的「兩個」世界的一種方法，我的意思是（a）適當的集中程度用於報告常見事物和（b）適當的專業化水平。增加的細微差別需要花費額外的加入時間，但會爲您提供靈活性和報告。

雖然我有點偏向於支持子類型，但有些人認爲，除非您的訂單子類型非常不同，否則可能不值得將它們分開。有一些看似很好的討論here on dba.stackexchange以及here。話雖如此，書籍（或至少章節）已經寫在這個問題上！

Answer 3

你的目標應該是讓一個數據庫設計沒有硬連接到有關其內容的細節，如果它確實（必須）它的確如此，從而將專業化從核心DB設計中分離出來。

每個訂單都有一些常見的字段。將這些放在一個表中，並將其引用到相應（專用）表中的其他行。這就是爲你的數據庫規範化。

您可以在主表中包含ID, OrderID, ItemType, ItemID，當ItemType確定表ItemID指的是表。我建議不要這樣做，但必須承認我有時會使用它。

更好的辦法是有這些表：

Clients:  ID, Name, Address, Phone 
Sellers:  ID, Name, CompanyAlias 

Orders:  ID, ClientID, SellerID, Date, Price 
OrderItems: ID, OrderID, DiscountAmount, DiscountPercentage, 
       ProductDomainID, ProductBottleID, ProductCheeseID, .. 

現在OrderItems是神奇在哪裏發生。前四個領域解釋自己我猜。而其餘的是指不改變或刪除過任何一個表：

Products_Cheese ID, ProductCode, ProductName, Price 

如果你需要一個特定的順序變型產品添加一個字段VariantOfID這就是否則爲NULL。然後參考該ID。

該OrderItems表可以添加字段，而不會干擾已建立的數據庫結構。只需限制自己在除0123之外的所有Product*ID字段中使用NULL值。但是，如果進一步考慮這一點，甚至可能會出現情景，希望將兩個或多個字段組合在一起。例如，添加與ProductCheeseID並排設置的或ExtraServicelevelagreementID字段。

---

如果使用ProductCheeseID + + ExtraServicelevelagreementID客戶可以訂購SLA一個奶酪訂閱，你的數據庫結構不會重演這樣。

這個基本的設計是開放的替代想法和解決方案。但保持你的結構分離。不要製作一張巨大的桌子，其中包含您可能需要的所有領域，一旦您必須稍後改變某些東西，事情就會突然崩潰。

Answer 4

在設計數據庫表時，您需要關注實體所代表的內容，以及具有兩個或更多略微不同版本的本質上相同的實體會使模式難以維護。訂單是訂單，對於不同的客戶，它們只是不同產品的不同訂單類型。你需要一些鏈接表來使所有的工作，但你必須以某種方式使這些協會，它擊敗了不同的實體類型。這對於一個非常粗糙的起點怎麼樣？

Answer 5

什麼是解決的最佳方式，並分割成每個單獨的順序表的最佳方式？

這取決於。它會隨着時間而改變。因此，這裏至關重要的一點是，您創建了訂單模型，並將它們的存儲與僅編寫處理這些模型的代碼分開。

完成後，您可以隨着時間的推移開發和更改數據庫結構，以存儲和查詢需要存儲並需要查詢的所有信息。

這是一般的建議。

更具體地說，您仍然需要將模型映射到數據結構。關於如何解決這個問題有很多方法，例如一個單獨的表，其中不是所有的列都被使用（平坦表），子類型表（每種類型使用一個新的表）或者具有包含附加列甚至屬性表的公共字段和子類型表的主表。所有這些方法都有優點和缺點，Stackoverflow的答案很可能是完全討論這些問題的錯誤地方。然而，你可以在這裏找到你的問題的精闢入門級的討論：

實體 - 屬性 - 值（第6章）;第61頁in SQL反模式 - 避免數據庫編程的缺陷作者：Bill Karwin。