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

Posted 2023-02-27

【中文标题】核心数据（SQLite/iPhone）——设计注意事项？

【英文标题】：Core Data (SQLite/iPhone) - design considerations?

【发布时间】：2009-11-25 06:50:22

【问题描述】：

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

场景如下：

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

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

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

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

核心数据存储

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

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

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

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

~~~

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

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

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

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

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

核心数据堆栈

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

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

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

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

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

~~~

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

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

提前非常感谢您！

【参考方案1】：

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

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

【讨论】：

谢谢你，路易斯！好点。这很有意义。需要明确的是：这意味着可能有数万个对象，都在同一个数据存储中？

Core Data 可以使用 SQLite 存储轻松地对 >1e6 对象进行操作，只要您一次在托管对象上下文中的内存中没有太多实例（iPhone 上的标准考虑因素）。

是的，巴里说的。我不想说得太具体，因为如果您有大量索引或 BLOB，性能下降的确切点可能会发生变化，但通常在电话上使用数十万到数百万就可以了。

太棒了——正是我需要的信息。非常感谢你们！根据您的建议，我已经开始实施修订后的统一设计。我现在明白为什么这是正确的方法，并且期待性能优势（更不用说它的简化实现了）。这真的是一个巨大的帮助！我非常感谢您如此慷慨地分享您的专业知识——再次感谢。