Какой подход лучше для этого сценария? - PullRequest
Новая
       11

Какой подход лучше для этого сценария?

1 голос
/ 25 августа 2010

У нас есть следующая таблица: 

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 насчитывает почти 4 миллиона записей и продолжает расти. Мы также проводим кампании, для которых не требуются купонные коды, и поэтому мы не вставляем эти записи. Теперь нам нужно также начать отслеживать эти кампании и для другой цели. Итак, у нас есть 2 варианта:

  1. Мы изменяем столбец CouponCode на NULL и создаем уникальный фильтрованный индекс, чтобы не включать NULL, и позволяем таблице расти еще больше и быстрее.
  2. Создайте отдельную таблицу для отслеживания всех кампаний для этой конкретной цели.

Имейте в виду, что таблица CampaignCustomer очень часто используется для погашения купонов и вставки новых. Суть в том, что мы не хотим, чтобы наш клиент использовал купон и ждал, пока он не сдастся или другие процессы не сработают. Итак, с точки зрения эффективности, какой вариант вы считаете лучшим и почему?

Ответы [ 2 ]

4 голосов
/ 26 августа 2010

Я бы выбрал отфильтрованный индекс ... вы храните те же данные, поэтому храните их в той же таблице.

Разделение таблицы - это рефакторинг, когда вам, вероятно, это не нужно, и добавляетсложность.

У вас есть проблемы с 4 миллионами строк?Это не так уж и много, особенно для такого узкого стола

2 голосов
/ 26 августа 2010
  1. Я против двойной таблицы ради одного столбца
  2. Разрешение couponcode быть нулевым означает, что кто-то может случайно создать запись, значение которой равно NULL, когда это должен быть действительный код купона

Я бы создал couponcode, который указывает на то, что он не является купоном, а не прибегает к столбцам индикатора "isCoupon" или "isNonCouponCampaign", и использовал бы отфильтрованный индекс, чтобы игнорировать значение "nocoupon".

Что приводит меня к следующему пункту - я не вижу ссылки на внешний ключ, но это было бы ключом к знанию того, какие купоны существовали и какие фактически использовались. Некоторые столбцы в существующей таблице могут быть перемещены в родительскую таблицу кодов купонов ...

...