我需要确保我的一张桌子可以处理超过1,000,000条记录。
我可以对我的表格代码提出一些建议,以确定它是否确实可以处理这一数量的记录。
这是我的代码:
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 :(得分:0)
几乎任何数据库中的几乎任何表结构都可以处理一百万条记录。这不是运行现代软件的现代计算机的大量记录。
您的结构看起来很合理。一个问题是字段是否总是足够大以保存数据中的值。看起来您正在使用SQL Server。声明varchar(50)
与varchar(8000)
的存储或性能没有区别。 “50”似乎对我不利。
另一个评论是您有一个DateModified
列。我建议您还保留修改的历史表。通常重要的是要知道变化的内容,变化的时间以及变更前的变化值。
在更高级的系统中,您不会将人员的地址和电话号码存储在与其唯一ID相同的表中。一个人可以有多个地址(送货地址,账单地址,家庭住址等)。一个人可以有许多电话号码(固定电话号码,手机号码,工作号码,工作移动电话等)。而且,您没有电子邮件地址,Facebook ID等字段。联系信息比表格中的几个字段更复杂。
最后,作为习惯问题,我几乎总是在每个表的末尾包含以下字段:
CreatedBy varchar(255) default system_user,
CreataedAt datetime not null default getdate()
这让我知道是谁以及何时创建了一行。