Create Table Table1 (PK int not null identity constraint pk primary key, Charcol1 char(10), Charcol2 char(10), Textcol text)
你可以在每页上存储总数为8096/(4+10+10)=338行的数据,忽略每行的额外开销。如果你用varchar(8000)字段存储量文本数据,假设你在这个字段中有8KB的数据,那么你就可以在每页上存储一行。如果你的查询的主要内容就是返回文本字段,这个存储引擎优化会给你带来大大的好处。如果你的查询的主要内容是返回文本字段,那么你就会希望使用text in row选项了。text in row表选项将文本数据存储在一个单个的数据库页面上,如果文本的数量少于配置的限制的话。
SQL Server 2005将会提供一个peer-to-peer (P2P)的复制模式,专为在多个服务器上分散统一的数据集合所用,并且保持他们的同步性。一个节点的更新将会复制到拓扑结构内所有其他节点中:当一个节点重新在线,它会以P2P的模式与其他节点中发生的更新同步。这种解决方案的设计目标是将位于不同地理位置的服务器的规模按照比例缩小。
然而,在大多数的横向分割实现过程中,每个服务器或数据库都包含数据的子集。在SQL Server 7之前的版本上,这些实现是在应用程序的级别上完成的,在那里调用应用程序根据查询参数(SARG)来决定访问那个表。如果表在同一个数据库内分割,T-SQL逻辑就需要负责分割,这样每个正确的分割都可以参考或者更新。如果你创建了一个视图来表示一个完整的结果集,所有的潜在的基本表都需要参考到。
分布式分割视图
在SQL Server 7中,查询优化器将会考虑查看执行计划中的约束。如果你在某个字段上有检查约束,并且你的SARG参考了这个字段,那么只有正确的分割可以在执行计划中参考。考虑一个在姓者个字段上有检查约束的表,如下所示:
CONSTRAINT [CK_Employee] CHECK ([LastName] > 'a' and [LastName] < 'b')
Select * from EmployeeTableView where LastName ='a'
然而,插入、更新和删除都需要在正确的基本表上执行。在SQL Server 2000种,你需要执行数据管理语言来操作这个视图,以及参考的正确的基本表。
SQL Server 2005中的分割
SQL Server 2005,于2005年11月发布,引入了一些数据库分割方面的加强,改善了性能并减小了有关管理分布式数据集的管理负担。
在SQL Server 之前的版本中,需要你手工创建表来形成分割。在我们上面举出的例子中,我们需要创建26个表(每个表代表一个字母)来形成雇员的分割。在SQL Server 2005中,你可以创建一个分割函数,然后通过这个函数来分割表,同时SQL Server 还会根据你的范围函数确定的不同分割内的数据分散。这看起来像是一个表。出于性能的原因,你也许还想要分割的表扩展到多个文件群(可能在不同的磁盘或者阵列中),每一个分割都分配到他自己的文件群中。要做到这一点,你就需要创建一个分割计划,其中包括了所有的文件群来形成你的分割,然后创建你的表来使用这个分割计划,代替普通的文件群。
你还可以创建分割索引。在默认情况下,在一个分割上创建的索引可以与分个表使用同一个分割计划。有关如何使用SQL Server 2005的分割能力的最好资源就是Kimberly Tripp的白皮书。
总结
两种分割方式都具有其优势和弱点。SQL Server 2000为你的数据库分割提供了好几种选择:纵向分割通过非标准化和小心使用文本数据类型字段,用于缩小数据行的有效宽度。横向分割打破了VLDB(超大型数据库)表,根据范围形成了小一些代表。SQL Server 7中的查询优化器也意识到了检测约束,并且指挥参考符合条件的基本表。另一方面,SQL Server 2000还允许你通过P2P的复制模式来按照比例缩小规模,简化分割解决方案的创建和管理。
作者简介:Hilary Cotter进入IT这一行已经超过20年了,现在是网络和数据库顾问。微软在2001年最先嘉奖Cotter为微软SQL Server MVP。Cotter在多伦多大学机械工程专业获得了应用科学学士学位,接着在卡尔加里大学学习经济,在伯克利学院学习计算机科学。他撰写了一本有关SQL Server事务复制的书,现在致力于一本有关合并复制和微软的查询技术的书。