我一直在开发的应用程序的基本思想是允许用户组在闪存卡的“堆栈”上进行协作。最终，该应用程序将作为客户端-服务器系统运行（以 iOS 应用程序作为客户端，Rails 应用程序作为服务器）
在我看来，这种设计的要求是这样的：
- 它需要平滑地处理编辑的合并。因为许多用户将编辑每个堆栈，并且因为每个客户端可能无法在完成后立即上传他们的更改，所以设计需要能够优雅地协调对共享数据的不一致更改。
- 它需要高效。因为许多用户将通过他们的蜂窝连接访问应用程序，我需要最大限度地减少从服务器上传和下载的数据量，以确保应用程序在这些连接上快速运行，并减少已经有限的客户端的数据使用。
最初我只是走简单的路线，让客户端在每次同步时向服务器发送“批量”报告，这意味着将上传每个堆栈的整个本地副本，然后服务器将处理所有这些，将其与以前客户的编辑合并到自己的主副本中，然后将整个新数据集发送给客户，客户将保存此准确副本以供离线查看和编辑。
记住我的设计要求，我看到的问题主要是它非常低效。客户端应用程序不仅要浪费时间上传和下载所有这些数据，它还必须将所有新信息写入其本地数据存储，即使其中大部分与之前的副本相同。我也无法理解服务器如何以有效、合乎逻辑的方式理解冲突编辑。
所以这就是我想出的：
每当客户端对共享堆栈进行更改时，除了更改自己的数据库副本外，它还会在日志中记录更改，包括更改的内容、更改的方式、时间和由谁更改。下次客户端与服务器同步时，无论是在一秒钟内还是几天内，此操作“收据”都会发送到服务器，而不是整个本地数据副本。
在那里，服务器首先存储这些操作以供后代使用，然后再对服务器数据副本执行所有更改。然后，它使用这个收据数据库来获取自上次客户端与数据库同步以来对堆栈的所有相关更改。然后只有这些被发送回客户端，客户端在自己的本地副本上运行更改。
使用客户端所做的所有更改的日志，服务器可以决定哪些更改使哪些其他更改无效（例如，如果用户删除了一张卡片，然后在与此更改同步之前，另一个用户编辑了正常的卡片，那么删除将无效）。虽然实现起来很复杂，但理论上这将是我合并问题的理想解决方案。
所以你怎么看？
这是一个可行的解决方案吗？你看到我的总体规划中有什么明显的漏洞吗？
谢谢！