减少冗余的SQL表设计

Question

我有两种设计。想看看你们哪一个更合适。

所以我有三个表 offer，offer_type 和 offer_type_filter。

桌子的原创设计

报价

 id                      int(10) unsigned    
 code                    varchar(48)         
 offer_type_id           int(10) unsigned 
 start_date              datetime            
 exp_date                datetime            
 value                   int(10)             
 updated                 timestamp           
 created                 datetime            

offer_type

 id                      int(10) unsigned         
 name                    varchar(48)              
 condition   varchar(512)             

offer_type_filter

 id                      int(10) unsigned 
 filter_type             varchar(20)      
 filter_value            varchar(50)      
 offer_type_id   int(10) unsigned 

现在大家可能都猜到了，offer 有一个类型，并且 filter 指定了在什么特定情况下 offer 将适用。如果您想知道，那么 offer_type.condition 主要是购买最低 20 美元。 300 美元。 Offer_type_filter 是将此优惠仅适用于麦当劳。优惠可以在没有过滤器的情况下存在。

当前设计的一个问题是，每次创建新报价时，即使类型相同，我也必须在报价类型中创建一个重复条目，然后在报价类型过滤器中使用该类型（使用当前类型会弄乱现有报价）。

因此，就数据库重新设计而言，很明显 offer_type 不能存在于 offer_type_filter 中，所以我确信它必须更改为类似的东西

重新设计（取消 offer_type_filter 并创建新的表过滤器。基本上是重命名为更合适的名称）

过滤器

id   int(10) unsigned 
filter_type  varchar(20)      
filter_value     varchar(50)      
filter_type_set_id   int(10) unsigned 

对于其他表格，我正在考虑这两个选项

选项 1（重新设计的 offer_type_filter + 与原始设计相同的其他表）

报价

id   int(10) unsigned    
code     varchar(48)         
offer_type_filter_mapping_id     int(10) unsigned    

offer_type_filter_mapping

id   int(10) unsigned 
filter_type_set_id   int(10) unsigned     > from Filter table
offer_type_id    int(10) unsigned    

如果我选择第一个设计，那么我将在 offer_type_filter_mapping 中有多余的条目。对于没有过滤器的商品，offer_type_filter_mapping 将包含 offer_type_id 条目，其中 null 作为 filter_type_set_id。此外，对于我创建的每种类型，我都必须在映射表中添加一个条目。所以我不喜欢这方面的设计。

选项 2（重新设计的 offer_type_filter + 与原始设计相同的其他表）

报价

id   int(10) unsigned    
code     varchar(48)         
filter_type_set_id   int(10) unsigned    > from Filter table

我之所以选择选项 2，只是因为在这种情况下，每个报价都有多余的 filter_type_set_id 并且在我的情况下报价表很大

希望您对您认为哪种设计最痛苦的设计提出批评。常见用例：创建大量带有和不带有过滤器的报价。我们已经有近 40-50 种优惠类型。类型表无法涵盖所有​​场景，因此我们确实有 10% 的时间会创建新类型。

我还使用 Spring 和 Hibernate，因此您也可以从这个角度思考我的设计约束是什么。

附：您甚至可以在 mysql 中添加，像在 offer_type_filter 中那样为每个表生成两个 id 并不方便，但我正在考虑它。可能使用虚拟表生成或使用外部生成的 id。

Answer 1

我是这么看的，一个offer只能有一个offer type_filter，所以是1:N的关系

并且 offer 将采用您之前拥有的 offer_type 属性。

基数是 N:M

编辑：
例如，如果您在 offer_type_filter 中有。

offer_type_filter_id = 1 and it's 30% off.
offer_type_filter_id = 2 and it's 10% off.
offer_type_filter_id = 3 and it's 0% off.
...
etc

在您的报价表中，您可以拥有：

offer_id=1 and offer_filter_id=1 //this mean that product 1 has 30% off
offer_id=2 and offer_filter_id=1 //this mean that product 2 has 30% off
offer_id=3 and offer_filter_id=2 //this mean that product 2 has 10% off
offer_id=4 and offer_filter_id=3 //this mean that product 2 has 0% off

...

etc

如果你的基数是一个offer可以只有一个offer类型，是第一个设计。

如果你的基数是一个offer可以有多个折扣并且多个产品的折扣相同，我推荐第二种设计