SQL表设计减少冗余

Question

I have two designs in mind. Wanted to check which one is more optimum as per you guys.

So I have three tables offer, offer_type and offer_type_filter.

Original Design of tables

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 

Now as you all may guess that offer has a type and filter specifies in what specific cases offer will apply. If you are wondering then offer_type.condition is mainly for 20$ off on purchase of min. 300$. Offer_type_filter is to apply this offer only for say McDonalds. Offer can exist without filters.

One prob with current design is that every time I create new offer, even though type is same I have to create a duplicate entry in offer_type and then use that type in offer_type_filter (using current type will mess up existing offers).

So in terms of database re-design it is quite obvious that offer_type must not exist in offer_type_filter so I am convinced it has to change to something like this

Redesign (Doing away with offer_type_filter and creating new table filter. It's basically renaming to something more appropriate)

Filter

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

For other tables I am thinking of these two options

Option 1 (offer_type_filter from redesign + other tables same from original design)

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    

If I choose first design then I will have redundant entries in offer_type_filter_mapping. For offers which don't have filters, offer_type_filter_mapping will have entries of offer_type_id with null as filter_type_set_id. Also then for each type I create, I will have to put an entry in mapping table. So I don't like this aspect of design.

Option 2 (offer_type_filter from redesign + other tables same from original design)

offer

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

I came to Option 2 only because in this case there is redundant filter_type_set_id for each offer and in my case offer table is huge

Wanted your critique as to which design do you think is the least painful. Frequent Usecases: Creating lots of offers with and without filters. We already have close to 40-50 Offer types. The types table is not able to cover all scenario so we do create new types 10 % of the times.

Also I use Spring and Hibernate so you can think from that perspective too what my design constraints would be.

PS You might even add that in mysql it is not convenient to generate two id's per table as in offer_type_filter but I am thinking about it. Prob use a dummy table for generation or use an externally generated id.

Answer 1

I see it this way, one offer can have only one offer type_filter, so it makes a 1:N relationship

and offer will take the offer_type attributes that u had before.

the cardinality is N:M

EDIT:
for example, if you have in 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

and in your offer table you can have:

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

If your cardinality is one offer can be have only one Offer type, is the first design.

if your cardinality is one offer can have multiple discounts and the same discount for multiple products, I recommend the second design