我的应用是一个音乐库应用,用户有他们的歌曲,他们可以创建播放列表 我希望播放列表中歌曲的顺序符合用户将这些歌曲添加到该播放列表的顺序。
我的核心数据对象:
Song
=====
name
duration
album
artist (to one relationship)
Playlist
========
title
songs (to many relationship)
我有播放列表的表格视图,该表格中的每一行都显示播放列表的标题以及添加到该播放列表的最后一首歌曲的名称。
我有两个问题:
答案 0 :(得分:7)
在核心数据编辑器中将关系类型设置为已排序。这意味着您现在可以获得NSOrderedSet
首歌曲,而不仅仅是NSSet
首歌曲
答案 1 :(得分:4)
您可以通过向数据模型添加新实体来明确地对订单建模。
PlaylistOrder
=============
index (an integer of some type)
playlist (to one relationship)
song (to one relationship)
当您提取PlaylistOrder
个托管对象时,请按播放列表title
进行过滤,然后按index
排序。
为什么不将index
属性添加到Song
实体?据推测,一首歌可能属于多个播放列表。
答案 2 :(得分:1)
有序关系很昂贵。除非根本没有其他方法对数据进行排序,否则应该避免使用它们。在您的情况下,还有另一种方法可以对数据进行排序。
如果您向insertedAt
实体添加了createdAt
或Song
属性,那么您现在可以对其进行排序并获取歌曲的顺序。与使用有序关系相比,这将更快,性能更好。当您收集更多数据时,这一点就会变得更加明显。
从那里你可以对那个新属性上的Song
个实体进行排序,甚至可以在Playlist
实体中构建一个方便的方法来确定最后的Song
是什么(按日期属性排序,抓取最后一个对象)。
由于歌曲可以在多个播放列表中,因此您可以在播放列表和歌曲之间创建元对象。实际上是一个包含数据的连接表:
Playlist <<--> SongMeta <-->> Song
SongMeta
实体将createdAt
作为属性,然后它会为您提供一个位置,以便在该播放列表中添加有关该歌曲的其他信息。我过去在音乐应用程序中看到过这种设计。
但是,如果您预见到用户可以随意重新安排播放列表,那么这肯定属于有序关系的狭窄有用范围。请注意与之相关的性能成本。