0

2つのデザインを考えています。あなたたちにとってどちらがより最適かを確認したかったのです。

したがって、offer_type と offer_type_filter という 3 つのテーブルがあります。

テーブルのオリジナルデザイン

オファー

 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 は、このオファーをマクドナルドなどにのみ適用します。オファーはフィルターなしで存在できます。

現在の設計の 1 つの問題は、新しいオファーを作成するたびに、タイプが同じであっても、offer_type で重複するエントリを作成し、そのタイプを 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

他のテーブルについては、これら2つのオプションを考えています

オプション 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 には、filter_type_set_id が null の offer_type_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 を使用しているので、その観点から私のデザインの制約がどうなるかを考えることができます。

PS mysql では、offer_type_filter のようにテーブルごとに 2 つの ID を生成するのは便利ではないことを追加するかもしれませんが、私はそれについて考えています。生成にダミー テーブルを使用するか、外部で生成された ID を使用する可能性があります。

4

1 に答える 1

0

私はそれをこのように見ています、1つのオファーは1つのオファーtype_filterしか持つことができないので、1：Nの関係になります

ここに画像の説明を入力してください

そしてofferは、uが以前持っていた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

カーディナリティが1つのオファーである場合、オファータイプは1つだけにすることができ、これが最初のデザインです。

カーディナリティが1つのオファーである場合、複数の割引と複数の製品の同じ割引が可能である場合は、2番目のデザインをお勧めします

于 2012-05-24T17:38:05.260 に答える