核心数据与同一实体的多个关系
我有一个数据模型，正在尝试从基于 SQLite 的表结构移植到核心数据模型。我的 SQLite 结构有一个 Zones 表和一个 TransitLogs 表。 TransitLog 可以具有以下内容（在我的 sqlite 架构中） 起始区域 ID end_zone_id
其中每一个都是区域表的外键。这在 SQL 中工作得很好。但是当转向核心数据时，我很难理解如何对此进行建模。
我的第一次尝试让我在 TransitLog 实体中有两个关系，其中 startZone 和 endZone 关系属性指向一个区域（抱歉无法发布 xcode 的屏幕截图，因为这是我在这里发布的第一篇文章）
我的问题是如何处理 startZone 和 endZone 关系属性的逆关系。我不需要它们吗？在我读过的有关该主题的文档和书籍中，最好始终使用逆关系，但我想知道这种特殊情况是否不适用。或者我只是在核心数据中错误地对此进行建模。
感谢您的任何建议。
麦克风
I have a data model I'm trying to port from a SQLite based table structure to a Core Data model. My SQLite structure has a Zones table and a TransitLogs table. A TransitLog can have the following (in my sqlite schema)
start_zone_id
end_zone_id
Each of which is a foreign key to the zones table. This works fine in SQL. But when moving to Core Data I'm having trouble understanding how to model this.
My first attempt has me having two relationships in my TransitLog Entity with a startZone and endZone relationship attributes that point to a Zone (sorry wasn't able to post a screenshot of xcode as this is my first post here)
The question I have is how to handle the inverse relationship for the startZone and endZone relationship attributes. Do I not need them? In the documentation and books I've read on this topic, it's best to always use an inverse relationship but I'm wondering about this particular situation if it doesn't apply. Or am I simply modeling this incorrectly in Core Data.
Thanks for any advice.
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以在指向 TransitLog 的 Zone 实体中拥有两个独立的对多关系，称为
startLogs和endLogs。这些分别是startZone和endZone的倒数。You can have two separate to-many relationships in the Zone entity that point to TransitLog, called something like
startLogsandendLogs. Those would be the inverses forstartZoneandendZone, respectively.重要的模型版本控制和迁移可能会成为实时消耗——尤其是第一次。出于这个原因，除了 Apple 建议使用它们之外，我还建议添加反向关系。
也就是说，我发现至少有一种情况，添加逆关系根本没有意义 - 并且一切正常。但在这种情况下，要找到反向关系有用或必要的场景（并且仍然如此）极其困难。
Nontrivial model versioning and migration can be a real time sink - especially the first time. For that reason, as well as that Apple recommends using them, I would recommend adding the inverse relationships.
That said, I have found at least one case where it simply did not make sense to add an inverse relationship - and everything works fine. But in that case there it was (and remains) extremely difficult to find a scenario where the inverse relationship would ever be useful or necessary.
谢谢大家 - 这两个答案都有很大帮助。 Westsider 是对的，我目前不需要从该区域遍历到 TransitLogs，这就是我想知道的原因。但话虽这么说，我想我可能在某个时候需要它们（希望有成千上万的用户强烈要求;））所以现在可能更好地对其进行建模。
再次感谢您的回答。
Thanks guys - both answers helped a lot. Westsider is right I currently have no need to traverse from the zone down to the TransitLogs and was why I was wondering. But that being said I guess it is possible that I might need them at some point (thousands of users clamoring for it hopefully ;)) so probably better to model it now.
Thanks again for the answers.