Database 为该数据建模的替代/快速方法

我们的SaaS应用程序帮助电子商务商店创建更有效的促销活动。为了做到这一点，我们需要保留相当多的数据——促销数据加上这些促销活动与应用这些促销活动的每个客户群相关的所有产品。我已经对这些数据进行了规范化，但我觉得其中一个表，promotion\u products，可能增长太快，减慢了我们最关键的查询速度

这张表是如何快速填充的：如果一家商店有25000种产品，并且每周在10个客户群中进行一次促销，那么促销商品表每周将有250000个新条目（100万个/mo）。由于这是一个SaaS产品，我们有许多客户创建相同数量或更多的数据

如何改进此模式，以便快速查询促销产品中的数据

products
  - product_id
  - customer_id
  - name

promotions
  - promotion_id
  - customer_id
  - promotion (i.e. 20% off etc)

promotion_products (need fast read access)
  - product_id
  - promotion_id
  - customer_id
  - group_id (each offer is associated w/ one or many customer groups)

---

通过将customer\u id添加到promotion\u products表中，您似乎对其进行了一点非规范化处理，这应该会有所帮助，尤其是如果它已被索引。您也可以考虑按客户和ApvestOrthId.E/P>对促销产品表进行聚类。 我想知道为什么在促销产品中使用组id和客户id，因为一个组id似乎与多个客户相关，这似乎是冲突的

请确保为您要查询的所有字段编制索引