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

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

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

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

Источник

2 ответа

Решение

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

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

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

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

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

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

Источник
Другие вопросы по тегам