我正在创建一个基于浏览器的应用程序，它允许用户拥有一个或多个项目，每个项目都有许多子实体。
我希望用户能够默认离线工作，并将更改同步或保存到包含所有数据的中央数据库（用户 - ＆gt;项目 - ＆gt;实体... ）。
问题涉及将来自客户端的生成的实体ID值映射到服务器上的ID，使得用户的数据不会因具有相似ID的实体而发生冲突。
我最初的想法是添加一个＆＃39; user_id＆＃39;服务器上每个实体的列，但使其对基于浏览器的应用程序透明。
例如，在应用的用户实例中，他们使用＆＃39; project_id＆＃39;创建了一个新项目。 = 1，当同步服务器接收新项目并将数据存储在等效表（具有附加的＆＃39; user_id＆＃39;列）时，并将user_id设置为请求保存操作的用户。
但是，这种方法需要服务器上的每个表都有双主键。它只是感觉很奇怪，并想要一个更好的方法，涉及剂量（GUID）。
感谢。
答案 0 :(得分：0)
UUID / GUID只是128位数字，因此它们具有如此大的范围，因此很容易生成随机数，而不用担心冲突。如果您使用的是64位数字，那么随机生成一个数字是不安全的，因此您需要一个编号方案。通常，数据库只会使用自动递增字段处理此问题，但如果您需要脱机或其他客户端生成的ID，则可以通过两种方式实现此目的：
单一递增计数器
联系服务器一次并保留一系列数字。这可以在具有SQL事务的单个表中实现，也可以在具有Redis等原子计数器的任何数据库中实现。如果需要保留1000个数字，则以增量形式发送1000。如果之前的数字是1234，那么1234 + 1000 = 2234，现在您可以安全地为您的用户使用1235-2234。
您可以设置增量以允许足够的ID，而无需再次联系服务器。可能有几百万，而且有64位数字，你不必担心空间不足。
Hi / Lo策略
使用数字的“更高”部分作为预订，使用“更低”部分作为客户端的递增ID。所以12450的较高部分+ 234678的低部分= 12450234678作为实际ID号。这基本上就像有两个单独的键列，但组合成一个数字。它需要严格分割数量，以免意外重叠。
较高的部分可以使用上面选项1中较小的单位数增量来完成，也可以使用用户的ID（这可能会限制可用的总生命周期数）。
我已经在多个应用程序中成功使用了递增计数器选项，包括服务器/客户端脱机情况以及用于处理的分布式ID，以及在不同服务器上向数百万行添加唯一但仍在递增的ID。