使用核心数据，我有两个具有多对多关系的实体。所以：
Class A <<---->> Class B
这两种关系都设置为＆＃39; ordered＆＃39;所以我可以跟踪他们在UITableView中的订单。这很好，没问题。
我即将尝试使用此Core Data模型实现iCloud，并发现iCloud不支持有序关系，因此我需要以某种方式重新实现排序。
我已经与另一个没有任何问题的一对多关系的实体完成了这项工作，我添加了一个＆＃39;命令＆＃39;属性到实体并在那里存储它的订单信息。但是由于多对多的关系，我需要一个未知数量的订单属性。
我可以想到两种解决方案，对我来说似乎都不是理想的，所以也许我错过了一些东西;
选项1.我添加了一个中介实体。这个实体与两个实体都有一对多的关系，如：
Class A <<--> Class C <-->> Class B
这意味着我可以在这个帮助器实体中拥有单个order属性。
选项2.代替存储单个订单号的订单属性，我存储了一个字典，我可以根据需要存储多个订单号，可能是相应的对象（ID？）作为键和订单号作为价值。
我不一定要找任何代码，所以任何想法或建议都会受到赞赏。
答案 0 :(得分：1)
我认为您的选项1，使用带有订单属性的“连接表”是此问题最可行的解决方案。实际上，这在过去曾多次完成。这正是您在Core Data中使用连接表的情况，尽管该框架已经为您提供了多对多关系：如果您想存储关于关系本身的信息，这正是你的情况。通常这些是时间戳，在您的情况下，它是序列号。
你说：“......解决方案，对我来说似乎都不合理”。对我而言，上述似乎确实是“理想的”。我反复使用这个方案，性能和可维护性都很好。
唯一的问题（虽然它与一对一的关系相同）是，当不按顺序插入项目时，您必须更新许多实体以使订单正确。这似乎很麻烦，可能会损害性能。然而，在实践中，它非常易于管理并且表现相当不错。
注意：对于要与实体一起存储以跟踪排序信息的数组或字典：这可以通过所谓的“可转换”属性实现，但开销是令人生畏的。这些属性必须被序列化和反序列化，并且为了检索一个序列号，您必须获得所有。几乎没有吸引人的设计选择。
答案 1 :(得分：0)
在我们订购关系超过10年之前，每个人都使用了＃34;帮助＆＃34;实体。这就是你应该做的事情。
附加说明1：这不是＆＃34;帮助＆＃34;实体。它是一个模拟模型中事实的实体。在我的书中，我总是有同样的例子：
您有一个拥有成员的群组实体。每个成员都可以属于许多组。 ＆＃34;帮助＆＃34;实体只是会员资格。
附加说明2：很难同步这种有序关系。这就是为什么它不是自动完成的。但是，你必须这样做。由于CD和同步并不好玩，CD和同步模型与有序关系同步并不好玩。