数据库设计问题——将关系保持在最低限度
我有一个足够规范化的数据库设计，但现在我需要添加一个新表（实体，因为我实际上使用的是核心数据），并且遇到了一些问题。
景观有很多评估
评估有一种评估类型
评估树有一个评估
评估树有 12 个其他实体，因空间原因而省略。
现在，我添加一个照片实体，它可以与上述任何实体关联。我需要建立某种关系，以便我只能获取与评估树相关的照片，或者可能是评估，这将是与评估树相关的照片的超集。
（我觉得我可能没有很好地解释这种情况，所以如果我可以以某种方式澄清，请告诉我。）
我考虑过的可能解决方案，但没有一个令人满意：
- 创建对每个其他对象<的引用/em> 来自照片实体。零引用则意味着该照片不属于该集合的一部分。
- 创建一个新实体 PhotoRelations，它将保存对照片的引用以及对其所附加的对象之一的引用。问题是，虽然我可以使用 SQL 系统轻松完成此操作，但我不知道如何将其转换为 CoreData。
任何帮助将不胜感激！
I have a database design that's normalized well enough, but now I need to add a new table (entity, since I'm actually using Core Data) and I'm running into some issues.
Landscape has many Assessment
Assessment has one AssessmentType
AssessmentTree has one Assessment
AssessmentTree has one each of 12 other entities, omitted for space.
Now, I'm adding a Photo entity, which can be associated with ANY of the above entities. I need to have some sort of relationship in place such that I can grab only the Photos related to an AssessmentTree, for example, or perhaps an Assessment, which would be a superset of the Photos related to an AssessmentTree.
(I feel I may not have done a great job explaining the situation so let me know if I can clarify in some way.)
Possible solutions I've considered, none of which are satisfying:
- Create references to every other object from within the Photo entity. Nil references would then mean the Photo was not a part of that set.
- Create a new entity, PhotoRelations, that would hold a reference to the Photo and a reference to one of the objects it's attached. The problem is that while I could easily do this with an SQL system, I can't think of how to translate it into CoreData.
Any help would be appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Core Data 设计用来处理这个问题的方法是通过实体继承。
理论上，您可以像处理用子类定义的非核心数据对象一样处理这个问题。您将定义一个链接到具体照片实体的抽象父实体。然后，所有需要照片的实体都会从该父实体继承。
然而，由于 SQL 存储的实现细节，任何图中父实体的所有子实体最终都位于磁盘上的同一个 SQL 表中。这可能会降低获取性能，因为即使您只获取一个实体，也必须搜索存储在表中的所有子实体的所有实例。
很痛苦。我一直希望他们能够消除这种限制。
您可以使用测试数据来测试实体继承，看看这对于您的特定实现来说是否存在问题。如果您只有几千个获取简单属性（字符串、数字、日期等）的子实体，那么您可以使用实体继承，而不会造成任何重大性能影响。
The way that Core Data is designed to handle this problem is through entity inheritance.
In theory, you would handle this just the way you would with non-Core Data objects defined with subclasses. You would define an abstract parent entity that links to a concrete photo entity. Then you would have all the entities that need a photo inherit from that parent entity.
However, owing to an implementation detail with SQL stores, all the child entities of a parent entity in any graph end up in the same SQL table on disk. This can degrade fetch performance because all the instance of all sub-entities stored in a table have to be searched even if your just fetching one entity.
It's a pain. I keep hoping they will refractor that limitation out.
You could test the entity inheritance with test data and see if it is a problem or not for your particular implementation. If you have only a few thousand sub entities that fetch on simple attributes (strings, numbers, dates etc), then you may be able to use entity inheritance without any significant performance hit.
由于
Photo是一个子项，所以我会选择您的第一个选项并创建指向每个实体的链接。但是，您打算在照片中存储什么？如果它只是二进制数据，那么我会重新考虑它，并将图像的文件路径存储在磁盘上。在 Core Data 中存储二进制数据不太理想。然后，如果您只存储文件路径，您可能可以完全跳过该实体，而仅将 filePath 存储在父对象中。
Since
Photois a child then I would go with your first option and create a link to each entity.However, what do you plan on storing in Photo? If it is just the binary data then I would reconsider it and store a filePath to the image on disk instead. Storing binary data in Core Data is less than ideal. Then if you get down to just storing the file path you may be able to skip the entity entirely and just store the filePath in the parent object(s).
您可以做的是创建一个如下所示的关系表：
linkedId |照片ID | LinkType
LinkType 可以是上面列出的任何一个整数 1-N
What you could do is create a relation table like this:
linkedId | photoId | LinkType
LinkType can be any of the above listed as an integer 1-N