Core Data 有序的多对多关系
Core Data ordered many-to-many relationships
使用核心数据，我有两个具有多对多关系的实体。所以：
Class A <<---->> Class B
两个关系都设置为 'ordered'，因此我可以跟踪它们在 UITableView 中的顺序。很好用，没问题。
我正准备尝试使用这个 Core Data 模型实现 iCloud，发现 iCloud 不支持有序关系，所以我需要以某种方式重新实现排序。
我已经与另一个具有一对多关系的实体完成了此操作，没有问题，我向该实体添加了一个 'order' 属性并将其订单信息存储在那里。但是对于多对多关系，我需要未知数量的订单属性。
我可以想到两个解决方案，但对我来说都不是理想的，所以也许我遗漏了什么；
选项1.我添加一个中介实体。该实体与两个实体具有一对多关系，如下所示：
Class A <<--> Class C <-->> Class B
这意味着我可以在这个辅助实体中拥有单一订单属性。
选项 2。我存储了一个字典，我可以根据需要存储任意数量的订单号，而不是存储单个订单号的订单属性，可能以相应的对象（ID？）作为键和订单号作为值。
我不一定要寻找任何代码，所以任何想法或建议都将不胜感激。
在我们订关系10多年之前，大家都用一个"helper"实体。所以这就是你应该做的事情。
附加说明 1：这不是 "helper" 实体。它是一个在您的模型中模拟事实的实体。在我的书中，我总是有同样的例子：
您有一个包含成员的群组实体。每个成员都可以属于多个组。 "helper" 实体就是成员资格。
补充说明2：很难同步这样的有序关系。这就是为什么它不会自动完成的原因。但是，您必须这样做。由于 CD 和同步没有乐趣，CD 和同步具有有序关系的模型也不是没有乐趣。
我认为您的选项 1，使用带有订单属性的 "join table" 是解决这个问题的最可行的方法。事实上，这在过去已经做过很多次了。这正是您在 Core Data 中使用联接 table 的情况，尽管框架已经为您提供了 many-to-many 关系：如果您想 存储有关关系本身的信息 ，这正是你的情况。通常这些是时间戳，在您的情况下它是一个序列号。
您说：“...解决方案，对我来说都不是理想的”。对我来说，以上似乎确实"ideal"。这个方案我已经反复使用过，性能和可维护性都很好。
唯一的问题（虽然它与 to-one 关系相同）是当插入项目时乱序您必须更新许多实体以获得正确的顺序。这看起来很麻烦，并且可能会损害性能。然而，在实践中，它非常易于管理并且性能相当好。
注意：至于与实体一起存储的数组或字典以跟踪排序信息：这可以通过 so-called "transformable" 属性实现，但开销是令人生畏。这些属性必须被序列化和反序列化，并且为了检索 one 序列号，您必须获得它们的 all。几乎没有吸引力的设计选择。
使用核心数据，我有两个具有多对多关系的实体。所以：
Class A <<---->> Class B
两个关系都设置为 'ordered'，因此我可以跟踪它们在 UITableView 中的顺序。很好用，没问题。
我正准备尝试使用这个 Core Data 模型实现 iCloud，发现 iCloud 不支持有序关系，所以我需要以某种方式重新实现排序。
我已经与另一个具有一对多关系的实体完成了此操作，没有问题，我向该实体添加了一个 'order' 属性并将其订单信息存储在那里。但是对于多对多关系，我需要未知数量的订单属性。
我可以想到两个解决方案，但对我来说都不是理想的，所以也许我遗漏了什么；
选项1.我添加一个中介实体。该实体与两个实体具有一对多关系，如下所示：
Class A <<--> Class C <-->> Class B
这意味着我可以在这个辅助实体中拥有单一订单属性。
选项 2。我存储了一个字典，我可以根据需要存储任意数量的订单号，而不是存储单个订单号的订单属性，可能以相应的对象（ID？）作为键和订单号作为值。
我不一定要寻找任何代码，所以任何想法或建议都将不胜感激。
在我们订关系10多年之前，大家都用一个"helper"实体。所以这就是你应该做的事情。
附加说明 1：这不是 "helper" 实体。它是一个在您的模型中模拟事实的实体。在我的书中，我总是有同样的例子：
您有一个包含成员的群组实体。每个成员都可以属于多个组。 "helper" 实体就是成员资格。
补充说明2：很难同步这样的有序关系。这就是为什么它不会自动完成的原因。但是，您必须这样做。由于 CD 和同步没有乐趣，CD 和同步具有有序关系的模型也不是没有乐趣。
我认为您的选项 1，使用带有订单属性的 "join table" 是解决这个问题的最可行的方法。事实上，这在过去已经做过很多次了。这正是您在 Core Data 中使用联接 table 的情况，尽管框架已经为您提供了 many-to-many 关系：如果您想 存储有关关系本身的信息 ，这正是你的情况。通常这些是时间戳，在您的情况下它是一个序列号。
您说：“...解决方案，对我来说都不是理想的”。对我来说，以上似乎确实"ideal"。这个方案我已经反复使用过，性能和可维护性都很好。
唯一的问题（虽然它与 to-one 关系相同）是当插入项目时乱序您必须更新许多实体以获得正确的顺序。这看起来很麻烦，并且可能会损害性能。然而，在实践中，它非常易于管理并且性能相当好。
注意：至于与实体一起存储的数组或字典以跟踪排序信息：这可以通过 so-called "transformable" 属性实现，但开销是令人生畏。这些属性必须被序列化和反序列化，并且为了检索 one 序列号，您必须获得它们的 all。几乎没有吸引力的设计选择。