Hen*_*nry 2 database architecture sql-server web-applications uniqueidentifier
EDITED
当我们多年前首次构建我们的Web应用程序时,我们为所有用户的数据选择了自动增量int.但是,我们现在因为将特定用户的数据(具有一对多关系的多个表)传输到另一个非空数据库实例(具有相同的表限制)而变得多么困难.
虽然SET IDENTITY_INSERT table ON | OFF可能适用于某些表,但是对于我们当前的体系结构,我们仍会遇到问题,因为"一对多"关系中的某些"许多"可能会与目标数据库发生冲突.
受Pam Lahoud的回答启发,我开始研究非聚类PK和PK替代方案.然后,我遇到了从MSDN 为分布式环境选择适当的主键,并且"包含节点标识符的键"引起了我的注意.有人有这种架构的经验吗？
GUID作为主键是很棒的,GUID作为聚簇索引键不是那么棒.虽然PK确实默认为群集,但它不一定非必须.如果表上有另一列有意义进行群集,您可以考虑转换为非群集GUID主键并在其他某些字段上进行群集.
如果桌面上的PK经常被用于过滤和加入,那么即使它们是GUID,它们仍然有可能被聚类.使用newsequentialid()将解决由GUID聚簇索引键引起的大多数问题 - 即逻辑索引碎片,页面拆分和低页面密度.您仍然存在GUID是大数据类型的问题,因此所有索引(包括聚簇索引键和非聚簇索引,因为它们也包含聚簇索引键)将会稍大一些,但我认为这不一定是一个交易破坏者.
除了转换为GUID之外,我能想到的唯一其他解决方案是在每个数据库上指定标识范围并添加约束以确保它们之间的范围不重叠.这当然不适用于现有数据,但可以防止问题在未来发生,因为插入的新数据在您的服务器场中应该是唯一的.
与SQL Server中的任何内容一样,"始终"或"从不"规则很少,GUID作为主键和/或聚簇索引键是那些"依赖"规则之一,我认为在这种情况下GUID PK可能是正确的解决方案.