【问题标题】:Which approach is better for this scenario?哪种方法更适合这种情况?
【发布时间】:2010-08-25 19:54:01
【问题描述】:

我们有下表:

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 万条记录并且还在不断增长。我们还开展不需要优惠券代码的活动,因此我们不会插入这些记录。现在我们还需要开始跟踪这些活动以用于其他目的。所以我们有两个选择:

  1. 我们将 CouponCode 列更改为不允许空值,并创建一个唯一的过滤索引以不包含空值,并允许表更大更快地增长。
  2. 创建一个单独的表来跟踪所有针对此特定目的的活动。

请记住,CampaignCustomer 表经常用于兑换优惠券和插入新优惠券。底线是我们不希望我们的客户兑换优惠券并一直等到他们放弃或其他流程失败。那么,从效率的角度来看,您认为哪个选项最好,为什么?

【问题讨论】:

  • 没有 CouponCode 的广告系列有多少(百分比)?
  • 16.5% 的广告系列没有优惠券代码。
  • 有了这个比率,我会选择选项 1。但我会使用一个表示无优惠券记录的虚拟代码,而不是空值。您可能会考虑分区表...

标签: sql-server sql-server-2008 unique-index


【解决方案1】:

我会选择过滤索引...您存储的是相同的数据,因此请将其保存在同一个表中。

拆分表是在您可能不需要时进行重构,并增加了复杂性。

400 万行有问题吗?特别是对于这么窄的桌子来说,这并不算多

【讨论】:

  • 我们现在没有遇到 400 万行的问题。我们什么时候应该开始担心桌子的大小?我们不会存储相同的数据,而是相似的。
【解决方案2】:
  1. 为了一列,我反对重复表
  2. 允许couponcode 为空意味着有人可能会意外创建一条记录,该记录应为有效的优惠券代码,但其值为空

我会创建一个couponcode,表明它是非优惠券,而不是诉诸指标列“isCoupon”或“isNonCouponCampaign”,并使用过滤索引来忽略“nocoupon”值。

这引出了我的下一点——我没有看到外键引用,但它是了解存在哪些优惠券以及实际使用了哪些优惠券的关键。现有表中的某些列可以上移到父优惠券代码表...

【讨论】:

  • 所以你是说不要使用 NULL 而是插入“nocoupon”并过滤唯一键?
  • @Jonas Stawski:是的。我忘了它会被复制并打破你的独特约束。
  • @Jonas Stawski:是的,但 NULL 比明确传达记录不同原因的定义值更糟糕。
猜你喜欢
  • 2018-09-22
  • 2012-10-29
  • 2016-01-06
  • 2013-02-06
  • 2010-11-21
  • 2023-03-10
  • 1970-01-01
  • 2011-12-15
相关资源
最近更新 更多