如何设置新的SQL Server数据库以允许将来可能的复制？

Question

我正在构建一个系统,它有可能需要支持500多个并发用户,每个用户每分钟进行几十次查询(选择,插入和更新).基于这些需求和具有数百万行的表,我怀疑将来需要使用数据库复制来减少一些查询负载.

在过去没有使用过复制,我想知道在架构设计中是否还需要考虑什么？

例如,我曾被告知有必要使用GUID作为主键来启用复制.这是真的？
对于要复制的数据库,数据库设计有哪些特殊注意事项或最佳实践？

由于项目的时间限制,我不想在可能不需要时通过实施复制来浪费任何时间.(我现在有足够的明确问题需要克服,而不必担心必须解决可能的问题.)但是,如果/如果将来需要复制,我不希望必须进行可能可避免的架构更改.

关于这个主题的任何其他建议,包括学习实施复制的好地方,也将不胜感激.

Answer 1

虽然每行都必须有一rowguid列，但您不需要使用Guid 作为主键。实际上，您甚至不需要拥有主键（尽管您会因为未能创建主键而被石头砸死）。即使您将主键定义为 guid，不将其设为rowguid列也会导致复制服务为您创建一个附加列。你绝对可以这样做，这不是一个坏主意，但它绝不是必要的，也不是特别有利的。

以下是一些提示：

1. 保持表（或者更确切地说，行）大小较小；除非您使用列级复制，否则即使只有一列发生更改，您也将下载/上传一行的全部内容。此外，较小的表使冲突解决更加容易且频率较低。
2. 不要使用顺序或确定性算法驱动的主键。这包括标识列。是的，复制服务将自行处理标识列并分配密钥分配，但这是一个您不想处理的令人头痛的问题。仅此一点就是使用 Guid 作为主键的一个很好的论据。
3. 不要让您的应用程序执行不必要的更新。一开始这显然是一个坏主意，但从带宽使用和冲突解决的角度来看，这个问题在复制场景中会呈指数级恶化。