我的数据模型正在使用Core Data的继承，我可以考虑将这些数据存储到CloudKit Records中的3种策略。
在模型中让我们留下一个抽象类Element，以及两个子类：A和B
CloudKit策略1：创建记录类型A和记录类型B.每个记录类型包含基类及其关联子类型的参数
CloudKit策略2：创建记录类型元素。元素包含Element，A和B的所有参数，以及指示记录实际上是A类还是B类的字符串
CloudKit策略3：创建记录类型元素，记录类型A和记录类型B.每个包含与模型相同的参数。记录类型A和记录类型B还具有父元素
的附加参考参数我认为策略2是最容易实现的，但它会在云中占用更多空间。只有当我的应用程序实际起飞并且只专注于维护一个简单的CloudKit模型时，我是否应该担心浪费的空间？
策略3是否过度？
如果我使用策略1，在多个记录类型中多次复制所有字段似乎有点蹩脚。但这是通常做的吗？
可能取决于数据模型的实际大小。需要混淆的数据库部分有大约10个表。
哪一个是最好的策略？
答案 0 :(得分：0)
我可能会使用策略1，在您的应用中每个具体类别的记录类型，但如果您的类型A和B几乎相同，您可以使用策略2。
如果您将来在类型B中添加更多字段，则在策略2下，您必须将这些字段添加到为类型B或A 的对象创建的每条记录中，这样会感觉更少对我而言。
就代码复杂性而言，我怀疑使用策略1会比使用策略2更省力或代码。
策略3可能会带给你更多的努力和代码，而且我不会在其中看到很多好处。