optimization - 客户端能否可靠地为写入数据库的对象生成 PK？

Question

我一直在为这个困境大惊小怪一段时间，我想我会接近 SO。

我的场景的一些背景:

我有包含 0 个或多个 PlaylistItem 子项的播放列表。

很少创建播放列表。因此，我可以从服务器请求 GUID，等待响应，成功后刷新 UI 以显示成功添加的播放列表。

PlaylistItem 对象经常被创建。因此，我是 不正常 当我等待服务器以 UUID 响应时，带有加载消息。

我知道这最后一个事实是一种优化，但我认为它极大地提高了程序的可用性。

不过，我想讨论我唯一标识我的对象客户端的选项。我将首先强调我尝试过但失败的两个选项，然后是我正在考虑的第三个选项。我很想了解其他可能的解决方案。

生成一个 PK UUID 客户端，它将被持久化到服务器。

这是我的第一选择。这是一个显而易见的决定，但有一些明显的缺点。这里的第一个问题是客户端 UUID 不能也不应该被信任用于这种目的。恶意用户可以轻松地强制 PK 冲突。此外，我的理解是，如果我选择在客户端生成 UUID，我应该期待更大的碰撞机会。抓那个。

根据播放列表 GUID 和播放列表中的位置生成复合 PK

我认为这是一个棘手但很好的解决我的问题的方法。播放列表项的位置对于给定的播放列表集合是唯一的 和 它可以在客户端和服务器端派生。这似乎是一个很好的修复。不幸的是，让我的位置成为 PK 的一部分打破了我的 PK 的不变性。每当重新排序或删除 PlaylistItem 时——需要更新大量 PlaylistItem 键。抓那个。

基于播放列表 GUID 和自动递增的播放列表项 ID 生成复合 PK

此解决方案与上述解决方案类似，但通过将组合键与位置分离来确保 PK 不可变。这是我正在使用的当前解决方案。我唯一担心的是恶意用户可能会通过在发送之前修改客户端的自动递增 id 来强制冲突。我不认为这种恶意行为会对系统造成任何损害，但需要考虑。

好的!你有它。我做这一切是愚蠢的吗？我是否只是接受并强制我的服务器为我的 PlaylistItem 对象生成 GUID？或者，是否可以编写正确的实现？

更新:

我希望在服务器成功保存到数据库之前直观地表示用户的操作，并在保存失败时实现所需的恢复技术。我不确定这是否是愚蠢的，但我将通过一个用例场景来解释我的推理:

客户端想要添加一个新的 PlaylistItem。为此，需要向 YouTube 的 API 发出请求以获取创建 PlaylistItem 所需的所有信息。在 YouTube 的 API 做出响应后，客户端拥有创建 PlaylistItem 所需的所有信息，但唯一标识它的能力除外。

此时，用户已经为 YouTube 的 API 等待了 X 时间帧。现在，我想在客户端上直观地显示 PlaylistItem。如果我选择等待服务器，我现在正在等待 X + Y 时间范围，然后才会有成功的视觉指示。在测试中，这种延迟感觉很尴尬。

我的服务器只是 Amazon EC2 上的一个微型实例。我可以通过升级硬件来减少 Y 时间范围，但我可以通过巧妙的编程完全消除 Y。这是我面临的困境。

Answer 1

好的，当我在评论中建议时，您似乎喜欢它:)

您可以使用高/低方法，这基本上允许客户端一次保留一堆 key 。最简单的方法可能是使它成为一个复合主键，由两个整数组成。客户会有一个类似“给我一把主键”的电话。您将自动递增“下一个主键”序列，并记录哪个客户端“拥有”该主键。然后，该客户端可以在该主键旁边使用任何小键，并且知道它们将与任何其他客户端隔离。

当客户端执行插入时，您可以检查客户端是否使用了正确的主键，即分配给他们的主键。

当然，另一种方法是只制作主键 { client ID, UUID } 并让客户端指定任何 UUID ...