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

Question

Мы имеем следующую таблицу:

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

Answer 1

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

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

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

Answer 2

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

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

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