Ios CloudKit设计建议

让我先说一句，我知道使用CloudKit的利弊，我正在努力解决其中一个问题。然而，由于Cloudkit或多或少是免费的，这就是我正在使用的。我知道使用不同的框架可能会更容易

为了简单起见，让我们假设我正在制作一个社交媒体图像共享应用程序，我想跟踪照片喜好，我的框架是CloudKit。我正试图找出最有效的方法来追踪公众共享照片的喜好

我考虑过的几个选项：

每一个like都是公共数据库中的一个新记录，带有对照片的反向引用。由于CK没有聚合查询，为了显示照片的赞数，我需要查询给定引用的所有记录并对它们进行计数。如果这个数字变得非常大，那么我将在光标上迭代。这看起来写起来既快又准确，但显示大量照片的速度可能相当慢

like是私有数据库中的单个记录，我同时更新公共数据库中每个照片的单个记录中的聚合。现在，获取类总数是一个单记录查询。确定用户是否已经喜欢某样东西也变得更容易，因为喜欢的私有数据库较小。这条路线听起来是最快的，但如果多个用户喜欢同一张照片，它可能是不准确的。同时，删除一个用户和他们所有的私人爱好会使我的聚合保持不变，我需要一些过程来更新聚合

---

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

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

---

无论您选择什么解决方案，如果您想在删除用户后更新like，您都需要一个这样做的过程

如果你要否决投票，至少说一下为什么，任何人都可以点击按钮。顺便说一句，这很好，迫使我重新思考我的方法。做了很多重写，但事情就是这样。@rjb101你坚持这个解决方案了吗？您有两种不同的记录类型，一种是照片记录类型，另一种是单独的记录类型，用于聚合like计数（这是基于like本身的第三种记录类型），或者您只是在照片记录本身上聚合like计数？似乎避免中间聚合记录类型将避免对每张照片进行额外调用，并允许对照片的单个请求立即提供所有所需数据，尽管这可能会在更新照片时产生更多冲突，因为还可能发生评论更新等。想想看，我的两个场景似乎与你描述的略有出入。你能解释一下为什么在你的第二个场景中（你使用的那个场景）类似的东西在私有数据库中，而不是公共数据库吗？我看不出这些细节如何影响喜欢如何聚合的问题。