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_type.condition主要是购买分钟20美元。 $ 300。 Offer_type_filter仅适用于麦当劳。优惠可以不带过滤器存在。

当前设计的一个问题是，每次创建新商品时，即使类型相同，我也必须在offer_type中创建重复条目，然后在offer_type_filter中使用该类型（使用当前类型会破坏现有商品）。 / p>

因此，就数据库重新设计而言，很明显offer_type中不能存在offer_type，所以我确信它必须改为像这样

  

重新设计（取消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，因此您可以从这个角度思考我的设计约束是什么。

P.S。您甚至可以在mysql中添加它，如在offer_type_filter中为每个表生成两个id是不方便的，但我正在考虑它。 Prob使用虚拟表生成或使用外部生成的id。

Answer 1

我这样看，一个商品只能有一个商品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

如果您的基数是一个优惠只能有一个优惠类型，那么这是第一个设计。

如果您的基数是一个优惠可以有多个折扣和多个产品相同的折扣，我建议第二个设计