我正在设计Windows桌面应用程序。它使用LiteDB作为用户的单个文件本地数据库-非常用作具有外键等的关系数据库（每个表都具有整数ID作为主键，并通过FK整数引用其他表）。
这是一款复古游戏应用程序，因此“表”将包含以下内容：
系统（例如“ Sony PlayStation”，“ Nintendo 64”）
控制器（例如“ Sony Dual Shock”）
控件（例如“交叉”，“开始”，“选择”）
由于上述原因，我将不得不坚持使用整数ID作为主键-尽管我使用的是“名称”，但这不适用于控件（例如，在许多控制器上都可以找到“开始”）。
用户应该能够根据需要添加和删除记录（尽管不鼓励删除“标准”）
挑战在于，我还将在服务器上托管一个mysql数据库，从而允许用户从中更新其表。现在这是我无法理解的地方。
说他们将系统“ Casio Watch”添加到其本地表中。这将获得一个自动生成的ID（例如“ 94”）。同时，服务器数据库上会发生一些更新，并添加了新系统（例如“ Commodore Calculator”），这也会获得自动生成ID“ 94”。这是冲突编号1。
您可以通过将其附加为用户数据库中的新行来解决上述问题-在其中获得新的ID。但是我的第二个担心是关于外键。假设有一个带有“最大卖方”字段的“制造商”表。现在在服务器上，对于Manufacturer = Commodore，“ Commodore Calculator”的“最大卖方” FK为94。但是，如果将此Manufacturer表导入用户本地数据库，则Commodore的最大卖方将是“ Casio watch”-它的ID在用户数据库上为94。
请原谅我，如果我对所有这些都有些慢的话。即将出现参照完整性（是在更改时具有更新/空FK的那个？），但我认为您不能通过LiteDB做到这一点（即，其中的更改不会级联到相关表）。
任何建议将不胜感激。
答案 0 :(得分：1)
使用简单的自动递增字段将无法正确操作。
将“服务器ID”字段添加到相关表中，以标识数据来自的计算机/安装，并确保该字段在所有安装中都是唯一的。您需要在多个数据库之间进行同步的每个系统/制造商/等都将具有由服务器ID和自动递增值组成的复合主键（尽管您可能需要具有单独的生成器才能在本地创建自动递增）。因此，“ Casio Watch”的服务器ID为1，自动递增值为94。“ Commodore Calculator”的自动增量值相同，但其服务器ID不同，因此不会发生冲突。
另一个选择是使用通用唯一ID（UUID），而不是简单的自动增量字段。 UUID保证在所有mysql安装中都是唯一的（有一些限制）。在mysql中，您可以使用uuid()函数来生成uuid。
从系统设计的角度来看，UUID更简单，因为mysql在上述链接中描述的某些限制内保证了其唯一性。但是，UUID需要更多的存储空间，并且将具有negative impact on innodb's performance。