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

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

以下是场景：

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

• 大多数情况下，应用程序的用户（一次）将访问/修改一名学生的信息

• 偶尔，他们会弹出一个目录视图，其中显示了所有学生可供选择的列表

这是第一个大的设计问题：

核心数据存储

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

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

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

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

~~~

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

在这种情况下，我需要打开每个存储，检索学生的基本元数据，然后再次关闭它并移动到下一个文件

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

[事实上，我已经开始使用方法#2，但在迭代多个存储以创建“目录”视图时遇到了问题——因此，我想知道这是否是一种合理的开始方法

潜在的考虑因素包括：保持每个文件的大小易于管理；对象图的设计稍微简单一点；以及在存储因某种原因损坏时尽量减少数据丢失的可能性——但我不确定这到底是一个多大的实际问题。]

核心数据栈

--接下来，再次假设方法2：如何真正做到这一点

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

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

这些操作中哪些是昂贵的

。。。或者仅仅使用一个大型ish存储来处理所有数据会简单得多吗O

~~~

无论如何，我意识到这是一个复杂的问题，但任何指导都将不胜感激

我也希望这能帮助其他人在应用程序中使用核心数据

---

提前非常感谢

对于sqlite3 CoreData存储来说，拥有数百个项目的数百名学生通常不是问题，因此使用单个存储就可以了。您可能会想知道您想要索引哪些字段，但除此之外，一切都很好

---

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

对于sqlite3 CoreData存储来说，数百名学生和数百个项目通常不是问题，所以使用单个存储就可以了。您可能会想知道您想要索引哪些字段，但除此之外，一切都很好

---

在任何情况下，打开和关闭每个存储都要比以这种规模从单个存储中提取数据慢得多。如果您真的发现需要对数据进行切分，那么以合理的方式进行切分会复杂得多，我不会考虑如何处理它，直到您实际获得了性能数据，表明您可以这样做。不要担心用这种简单的方式浪费工作，因为与分片版本相比，这几乎不算什么，而且仍然可以让基本应用程序运行，以便开始评估用户界面和测试应用程序的可用性。

谢谢你，路易斯！很好的观点。这很有道理。需要明确的是：这意味着可能有上万个对象，都在同一个数据存储中？核心数据使用SQLite存储在>1e6个对象上很容易操作，只要一次在托管对象上下文中内存中没有太多实例（iPhone上的标准考虑）。是的，Barry说的。我不想说得太具体，因为如果你有大量的索引或blob，性能下降的确切点可能会发生变化，但在一般情况下，在电话上数十万到几百万就可以了。太棒了——这正是我需要的信息。非常感谢你们两位！根据你的建议，我已经开始做了