代码之家  ›  专栏  ›  技术社区  ›  Jonas Stawski

哪种方法更适合这种情况?

  •  1
  • Jonas Stawski  · 技术社区  · 16 年前

    我们有下表:

    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. 为此特定目的创建一个单独的表以跟踪所有活动。

    2 回复  |  直到 16 年前
        1
  •  4
  •   gbn    16 年前

    当您可能不需要拆分表并增加复杂性时,拆分表就是重构。

    400万行有问题吗?对于这么窄的桌子来说没什么特别的

        2
  •  2
  •   OMG Ponies    16 年前
    1. 为了一列,我反对重复表
    2. 允许 couponcode 为null意味着当值应该是有效的couponcode时,有人可能会意外地创建一个值为null的记录

    我会创造一个 表示为非优惠券,而不是诉诸指示符列“isCoupon”或“isNonCouponCampaign”,并使用筛选的索引忽略“nocoupon”值。

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