我有两个设计,想看看你们想看哪个更合适

我有三张桌子要买, 提供类型和提供类型过滤器。

表格原始设计

offer

 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 

正如大家可能猜想的, 报价有一个类型和过滤器, 指定了特定情况下的报价将适用。 如果您想知道, 则要提供_ 类型。 条件主要是购买 min. 300 $ 时 20 美元 。 Feral_ type_ filter 将只对“ 麦当劳” 适用此报价。 报价可以没有过滤器而存在 。

目前设计中的一个参数是,每次我提出新的报价,即使类型相同,我还必须在报价类型中创建一个重复的条目,然后在报价类型_类型_过滤器中使用该类型(使用当前类型将破坏现有的报价)。

因此,在数据库重新设计方面,非常明显的是,要价类型在要价类型_过滤器中不可能存在,所以我相信它必须改变成像这样的东西。

重新设计( 取消提供_ type_ filter 并创建新的表格过滤器。 它基本上改名为更合适的)

Filter

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

关于其他表格,我想到这两个备选方案。

备选方案1 (从重新设计中发价_类型_过滤器+与原设计中发价相同的其他表格)

offer

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_ maping 中有多余的条目。 对于没有过滤器的报价, offer_ type_ filter_ maping 将会有 offer_ type_ id 的条目, 无效为过滤器_ type_ set_ id 。 并且对于我创建的每一种类型, 我必须在绘图表格中输入一个条目。 因此我不喜欢这个设计方面 。

备选2(从重新设计中发价_类型_过滤器+从原设计中发价的其他表格)

offer

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

我之所以来到选项2, 是因为在此情况下, 每个报价都有多余的过滤器_ type_ set_ id, 在我的情况下, 报价表很大

想要你批评你认为哪个设计最不痛苦。 常见的用法: 创建许多有过滤器和没有过滤器的报价。 我们已经拥有近40- 50 提供类型。 类型表无法覆盖所有情景, 因此我们创造了10%的新类型 。

我用春与冬眠 也是为了让你从这个角度来思考 我的设计限制是什么

P. S. 你甚至可以补充一下,在 Mysql 中,每张桌子生成两个 id s 是不方便的,就像在 offer_ type_ filter 中那样,但我正在考虑。 Prob 使用一个假表来生成或使用外部生成的 id 。