CloudKit 设计建议答案

【问题标题】：CloudKit design adviceCloudKit 设计建议
【发布时间】：2015-12-01 20:42:12
【问题描述】：

让我先说我知道使用 CloudKit 的优缺点，并且我正在尝试解决其中一个问题。然而，由于 Cloudkit 或多或少是免费的，这就是我正在使用的。我知道使用不同的框架可能会更容易。

为了简单起见，假设我正在制作一个社交媒体图像共享应用程序，我想跟踪照片喜欢，我的框架是 CloudKit。我正在尝试找出最有效的方式来跟踪公开分享照片的点赞数。

我考虑过的几个选项：

每个赞都是公共数据库中的一条新记录，并带有对照片的反向引用。由于 CK 没有聚合查询，为了显示照片的点赞数，我需要查询给定引用的所有记录并计算它们。如果这个数字变得非常大，那么我将遍历光标。这看起来写起来又快又准确，但显示大量照片可能会很慢。
赞是私人数据库中的单独记录，我同时更新公共数据库中每张照片的单个记录中的聚合。获取总点赞数现在是一条记录查询。使用较小的私人喜欢数据库也可以更轻松地确定用户是否已经喜欢某物。这条路线听起来是最快的，但如果多个用户喜欢同一张照片，它可能不准确。删除用户和他们所有的私人喜欢也会使我的聚合保持不变，我需要一些更新聚合的过程。

我希望能得到任何建议，谢谢！

【问题讨论】：

【解决方案1】：

你的第二种方法是最好的，而且很准确。当您读取数据、更改并保存数据时，CloudKit 会同时检查数据是否更改。因此，当 2 人同时更新 1 张照片时，一个人会收到 CloudKit 错误，即数据已更改。然后再次尝试更新，直到成功。

无论您选择哪种解决方案，如果您想在删除用户后更新点赞，您需要一个执行此操作的流程。

【讨论】：

顺便说一句，这很好，迫使我重新考虑我的方法。做了很多重写，但就是这样。
@rjb101 你坚持这个解决方案了吗？我是对的，您有两种不同的记录类型，一种是照片记录类型，另一种是用于汇总点赞数的单独记录类型（基于点赞本身的第三种记录类型），还是您只是在照片记录本身？似乎避免使用中间聚合记录类型可以避免对每张照片进行额外调用，并使单个照片请求能够立即提供所有所需数据，尽管它可能会在更新照片时产生更多冲突，因为也可能会发生评论更新等.
想一想，我的两种情况似乎与您描述的情况略有不同。您能解释一下为什么在您的第二种情况（您使用的那个）中喜欢在私人数据库中而不是公开的吗？我看不出这个细节如何影响点赞如何聚合的问题。