1

次の表があります。

CREATE TABLE [dbo].[CampaignCustomer](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [CampaignID] [int] NOT NULL,
    [CustomerID] [int] NULL,
    [CouponCode] [nvarchar](20) NOT NULL,
    [CreatedDate] [datetime] NOT NULL,
    [ModifiedDate] [datetime] NULL,
    [Active] [bit] NOT NULL,
 CONSTRAINT [PK_CampaignCustomer] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

および次の一意のインデックス：

CREATE UNIQUE NONCLUSTERED INDEX [IX_CampaignCustomer_CouponCode] ON [dbo].[CampaignCustomer] 
(
    [CouponCode] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 20) ON [PRIMARY]
GO

CouponCodeと他の外部キーを使用してかなり一定のクエリを実行します（簡単にするために上記には示されていません）。CampaignCustomerテーブルには、ほぼ400万件のレコードがあり、増え続けています。また、クーポンコードを必要としないキャンペーンも行っているため、これらのレコードは挿入されません。次に、別の目的のために、これらのキャンペーンの追跡も開始する必要があります。したがって、2つのオプションがあります。

  1. CouponCode列を変更してnullを許可し、nullを含まないように一意のファイラーインデックスを作成して、テーブルをさらに大きく高速に拡張できるようにします。
  2. この特定の目的のためにすべてのキャンペーンを追跡するための個別のテーブルを作成します。

CampaignCustomerテーブルは、クーポンの引き換えや新しいクーポンの挿入に頻繁に使用されることに注意してください。結論として、お客様がクーポンを利用して、あきらめるまで、または他のプロセスが失敗するまで待たされたくないということです。では、効率の観点から、どのオプションが最適だと思いますか、またその理由は何ですか？

4

2 に答える 2

4

フィルター処理されたインデックスを使用します...同じデータを格納しているので、同じテーブルに保持します。

テーブルの分割は、おそらく必要がない場合にリファクタリングを行い、複雑さを増します。

400万行に問題がありますか？特にこんなに狭いテーブルの場合はそれほど多くありません

于 2010-08-25T20:02:19.457 に答える
2
  1. 私は単一の列のために重複したテーブルに反対しています
  2. をcouponcodenullにできるということは、有効なクーポンコードであるはずの値がNULLであるレコードを誰かが誤って作成する可能性があることを意味します

couponcodeインジケーター列「isCoupon」または「isNonCouponCampaign」に頼るのではなく、非クーポンであることを示すを作成し、フィルター処理されたインデックスを使用して「nocoupon」値を無視します。

これが私の次のポイントにつながります-外部キーの参照は表示されませんが、どのクーポンが存在し、どのクーポンが実際に使用されたかを知るための鍵になります。既存のテーブルの一部の列を親クーポンコードテーブルに移動できます...

于 2010-08-25T20:08:54.403 に答える