SQL表处理大量记录

问题描述:

我需要确保我的表可以处理超过1,000,000条记录。SQL表处理大量记录

我可以对我的表代码有一些建议,以确定它是否确实可以处理这一数量的记录。

这里是我的代码:

USE [db_person_cdtest] 
GO 
SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 
CREATE TABLE [Person](
    [PersonID] [numeric](18, 0) IDENTITY(1,1) NOT NULL, 
    [ID] [varchar](20), 
    [FirstName] [varchar](50) NOT NULL, 
    [LastName] [varchar](50) NOT NULL, 
    [AddressLine1] [varchar](50), 
    [AddressLine2] [varchar](50), 
    [AddressLine3] [varchar](50), 
    [MobilePhone] [varchar](20), 
    [HomePhone] [varchar](20), 
    [Description] [varchar](10), 
    [DateModified] [datetime], 
    [PersonCategory] [varchar](30) NOT NULL, 
    [Comment] [varchar](max), 
CONSTRAINT [PK_Person] PRIMARY KEY CLUSTERED 
(
    [PersonID] DESC 
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] 
) ON [PRIMARY]; 
+0

取决于你的查询你需要什么索引。 –

几乎在几乎任何数据库可以处理一百万条记录的任何表结构。对于运行现代软件的现代计算机来说,这并不是大量的记录。

您的结构看起来很合理。一个问题是这些字段是否总是足够大以保存数据中的值。它看起来像你正在使用SQL Server。宣布varchar(50)varchar(8000)的存储或性能没有差异。 “50”对我来说似乎偏低。

另一种意见是,你有一个DateModified列。我建议你也保留修改的历史表。了解变化之后发生了什么变化,什么时候变化以及变化之前的值是很重要的。

在更高级的系统中,您不会将个人的地址和电话号码存储在与其唯一ID相同的表中。一个人可以有多个地址(送货地址,账单地址,家庭住址等)。一个人可能有很多电话号码(固定电话号码,手机号码,工作号码,工作移动电话等)。而且,您没有电子邮件地址,Facebook ID等字段。联系信息比表中的几个字段更复杂。

最后,由于习惯问题,我几乎总是包括在每一个表的末尾以下字段:

CreatedBy varchar(255) default system_user, 
CreataedAt datetime not null default getdate() 

这让是我知道行创建谁当。