MSSQL编程：座谈SQL Server中的标识列(二)
BDB源自BerkeleyDB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性server这篇文章次要总结一下标识列在复制中的处置办法
1、快照复制
在快照复制中，一般不必思索标识列的属性。
2、事件复制
举例：
公布数据库A,定阅数据库B，出书物为T_test_A,定阅表为T_test_B
CREATETABLET_test_A
(IDintIDENTITY(1,1),
Namevarchar(50)
)
CREATETABLET_test_B
(IDintIDENTITY(1,1),
Namevarchar(50)
)
在这类情形下，复制代办署理将没法将新行复制到库B，由于列ID是标识列，不克不及给标识列显现供应值,复制失利。
这时候，必要为标识列设置NOTFORREPLICATION选项。如许，当复制代办署理程序用任何登录毗连到库B上的表T_test时，该表上的一切NOT
FORREPLICATION选项将被激活,就能够显式拔出ID列。
这里分两种情形：
1、库B的T_test表不会被用户(或使用程序)更新
最复杂的情形是：假如库B的T_test不会被用户(或使用程序)更新，那倡议往失落ID列的标识属性，只接纳复杂int范例便可。
2、库B的T_test表是会被其他用户（或使用程序）更新
这类情形下，两个T_test表的ID列就会产生抵触,举例:
在库A中实行以下语句:
INSERTT_test_A(Name)VALUES(Tom)(假定ID列为1)
在库B中实行以下语句:
INSERTT_test_B(Name)VALUES(Pip)(假定ID列为1)
如许，就会在库A和库B的两个表分离拔出一笔记录，明显，是两条分歧的纪录。
但是事变还没有停止，待到事后设定的复制工夫，复制代办署理试图把纪录"1TOM"拔出到库B中的T_test表，但库B的T_test_B表已存在
ID为1的列，拔出不会乐成，经由过程复制监督器，我们会发明复制失利了。
办理以上成绩的办法有：
(1)为公布方和定阅方的标识列指定分歧局限的值，如上例可修正为：
--确保该表纪录不会凌驾10000000
CREATETABLET_test_A
(IDintIDENTITY(1,1),
Namevarchar(50)
)
CREATETABLET_test_B
(IDintIDENTITY(10000000,1),
Namevarchar(50)
)
(2)使公布方和定阅方的标识列的值不会反复,如
--利用奇数值
CREATETABLET_test_A
(IDintIDENTITY(1,2),
Namevarchar(50)
)
--利用偶数值
CREATETABLET_test_B
(IDintIDENTITY(2,2),
Namevarchar(50)
)
这类举措可推行，当定阅方和公布方有到处时，标识列属性的界说分离以下
(1,4),(2,4),(3,4),(4,4)
3、兼并复制
接纳事件复制中办理办法,只需使公布表和定阅表标识列的值不反复既可。
虽然可以将一个droptable语句转换成先delete再删表，性能却会降低很多。这里我们用上面说道的另外一种可用数据：“操作前数据备份”。 一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。） 记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。 代替了原来VB式的错误判断。比Oracle高级不少。 可以动态传入参数，省却了动态SQL的拼写。 分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。 你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。 对于微软系列的东西除了一遍遍尝试还真没有太好的办法 原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！
页:
[1]