對於購物應用程序，建立ONE模型或TWO模型有什麼優點/缺點？

Question

附加上下文：

用戶每次購物時都可以購買一件或多件商品。我試圖找出兩種方法的優缺點。我已經寫出了我認爲每個人的優點（無需召喚出Cons，因爲一個Con可以寫成另一個的Pro），但我想從社區獲得反饋

方法1：

構建一個單一的模型，例如Items，其中每個項目在事務中都有一個記錄。

優點：

• 一般比較簡單，一個模型總是好的
• 良好比對的事實是，項目的價格，並取消/單獨退還（即有沒有真的什麼優惠或費用在發生這將是1）無法被分配到個別項目或2）不值得自己的模式購買水平）

方法2：

構建兩個模型，例如Purchases和Items，其中Purchases是代表該交易的父記錄，而Items是表示在該交易中購買的每件物品的子記錄。

優點：

• 對於商家來說，我認爲這是在兩個方面簡單：1）它更容易運行分析，以找出例如人們想要多少個項目在每次進行購買交易時間買（在方法1中這不是不可能的，但在方法2中肯定更容易），也許最重要的是：2）從履行的角度來看，發貨履行中心似乎更容易一個採購與許多項目，因爲交貨日期都將相同的，而不是一堆物品，他們然後必須聚合（再次這是不可能的方法1，但方法2更容易）

Answer 1

這可能會變得非常複雜，並且在過去我已經使用了更爲先進的＃2版本。您希望儘可能標準化您的數據（查找數據庫標準化以獲取更多信息），以便更輕鬆地運行報表，同時保持數據的一致性並減少重複。在一些真實世界的場景中，並不總是可以完全標準化，並且處理性能考慮也會在某些時候扮演重要角色 - 如果您完全規範化了數據，則會將數據分成許多小塊（例如表中的行），但要重建數據那麼你必須從多個位置（例如多個數據庫查詢）中檢索它，這會影響性能。

與＃2一起去吧，徹底計劃你在數據編碼之前如何構造數據。對於一個結構良好的模型，未來在系統上擴展應該是相當直接的。一個扁平結構可能成爲一個噩夢來維護。