核心数据（SQLite/iPhone）——设计注意事项？

Question

我正在设计一个 iPhone 应用程序，使用 Core Data 进行数据持久性（使用本地 SQLite 存储[s]）。在深入了解实现之前，我希望就一些与 Core Data 相关的基本设计问题提供一些定性建议。

场景如下：

• 该应用程序处理数十名（可能数百名）学生的数据 - 每个学生都有数百个单独的数据项（数字和文本）。

• 大多数时候，应用程序的用户将（一次）访问/修改一个学生的信息。

• 有时，他们会弹出一个目录视图，其中显示所有学生的列表以供选择。

所以这是第一个重要的设计问题：

核心数据存储

在这样的应用程序中，存储所有这些数据的最合理方法是什么：使用单个数据存储，或者可能使用多个存储？

方法#1： 将为所有学生的所有信息使用一个数据存储。

方法 #2： 使用多个商店，每个学生一个。 （请记住，每一项都有数百项数据。）

方法 #3： 也许是一种混合方法：多个存储，每个学生一个，使用单独的“索引”文件将所有学生的基本元数据与每个学生的个人存储的文件名相关联。

~~~

-- 假设片刻，方法#2： 这意味着访问特定学生数据时的简单性。但是，为了生成列出所有学生的“目录”屏幕，我需要遍历每个商店，以制表组装该列表所需的信息（名字、姓氏和每个人的一些其他项目）人——因此仅使用每个商店的文件名来表示元数据是不够的，也不可取）。

在这种情况下，我需要打开每个商店，检索学生的基本元数据，然后再次将其关闭并移至下一个文件。

这是低效的吗？开设/关闭可能数十家（或数百家）的个体商店是否昂贵？

[事实上，我已经开始使用方法 #2，但是已经在迭代多个商店以创建“目录”视图时陷入困境——因此，我想知道这是否是一种合理的开始方法和。

潜在的考虑因素包括：保持每个文件的大小易于管理；对象图的设计更简单一些；如果商店以某种方式损坏，还可以最大限度地减少数据丢失的可能性——但我不确定实际问题有多大。]

核心数据堆栈

-- 接下来，再次假设方法 #2：如何实际做到这一点？

要打开/读取/关闭特定商店，我应该重用单例上下文吗？ ……协调员？ （即，首先，从该上下文中删除任何打开的商店，添加下一个商店，然后以这种方式迭代？）或者为我需要迭代的每个商店释放并重建堆栈？

（一种可能的考虑是消除文件之间混合数据的可能性。）

这些操作中哪些是昂贵的？

... 还是首先使用一个大型存储来处理所有数据会更简单？ :O

~~~

无论如何，我意识到这是一个复杂的问题，但我们将非常感谢任何指导。

我也希望这有助于其他人也将 Core Data 用于他们的应用程序。

提前非常感谢您！

Answer 1

拥有数百个项目的数百个学生通常不会成为 sqlite3 CoreData 存储的问题，因此使用单个存储就可以了。您可能需要考虑要索引哪些字段，但除此之外一切都很好。

无论如何，在这些规模下，打开和关闭每个商店都比从单个商店中提取数据要慢得多。如果你真的发现你需要对数据进行分片，那么以一种合理的方式进行分片会更加复杂，而且我不会考虑处理它，直到你真正有性能数据表明你这样做了。不要担心以简单的方式做这件事会浪费工作，因为与分片版本相比，这几乎没有任何工作，并且仍然允许您运行基本应用程序，以便开始评估您的 UI 和测试应用程序的可用性。