我有一个现有的数据库，其中大多数表都有int主键（自动增量）。
我们现在处于这样的位置，我们现在需要将此数据库用作中央存储，并允许其他客户端连接并同步数据（上传/下载数据）
主键是自动增量键，我知道存在主键冲突的问题。
所以我想我可以为同步表添加一个全局密钥 - 比如一个GUID。
然后创建一个自定义同步逻辑查找此GUID /比较客户端
这听起来像是正确的主意吗？实现同步框架的任何其他建议，其中很少可以在中央数据库上更改（没有主键更改）
答案 0 :(得分：1)
您应该查看复制。我不知道它是否会对你的情况有所帮助。但复制通常使用GUID进行设置。
答案 1 :(得分：-1)
一般来说，自动递增键不会发生冲突;事实上，我不确定如何实现它（因为SQL中的大多数定义都包含Unique约束）。但是，您可能会遇到duplicate key错误。为什么让外部供应商决定你的内部密钥是什么？接受他们完成的记录，并自己生成密钥。如果您的密钥用完了，请增加列的大小（长）。您可以生成一个新的GUID列，是的，但是您仍然可能仍在生成GUID，那么有什么不同呢？
通常，数据库中的大多数表都有多个“唯一”键。这些是“自然”键 - 构成一组独特数据的实际列;不幸的是，这可能最终成为表的整个宽度（这就是使用id列的原因）。此外，除非有一些奇怪的用例，否则不要让服务器知道客户端ID - 让客户端了解服务器ID，并在客户端的单独列（如有必要）中跟踪它。然后可以拥有他们在上传之前使用的内部ID，这些内部ID与您提供的密钥无关 - 而且它们永远不会与服务器共享。
服务器ID是什么（基于int或GUID）并不重要，尽管我建议坚持使用你拥有的任何东西。每当客户端为您提供要放入服务器的行时，请从服务器返回生成的ID。这可以防止客户端尝试插入已经使用的ID以及相关问题（您如何知道他们给您的ID不应该由其他设备生成？）。我会说客户端无法在服务器上指示内部ID
<小时/> 编辑：
根据对复制的快速研究（回应HLGEM），并重新阅读原始问题;我最初提出的问题是询问让客户端指示内部主键（这仍然很糟糕），和/或用GUID替换int主键。虽然您的确切需求可能不需要它，但添加客户端可以填充的额外GUID列将起作用。一些建议：
1）将GUID列上的唯一密钥违规（意外或恶意）视为业务例外，而不是系统例外。我可能建议告诉客户端重新生成GUID并重新提交（静默）。
2）客户端永远不会指示数据库中的实际主键列值。实际上，如果您使用GUID列，客户端甚至可能根本不需要了解它们。