我将在 iPhone/Ipad 应用程序中使用相当复杂的数据结构。在摆脱了许多不需要的表并尽可能地扁平化数据结构之后。– 即，如果我在真实结构中有一个调用表和地址表，因为我根本不需要更新地址信息，我已经扩展了 IOS 调用表以包含地址信息而不是链接表 – 基本上是 de-尽可能标准化以降低表的复杂性。
总而言之，我还有 15 张桌子。
我可以轻松地将表编写到 SQLlite 中，并快速使用 IOS 中的 SQLlite C API 并让它正常工作。
我的问题是——对于一个包含大量相关表的失败的大型数据捕获应用程序，我应该坚持我的 SQL 技能并使用 SQLite 和 C API，还是将其全部转换为 coredata？
我对 coredata 的主要担心是 a) 设置时间——有没有办法从现有的数据库模式（SQL Server、SQLite 或脚本）创建 coredata 数据映射 b）如果我在一个表中有几千行（这是一个用于作业的库存物品清单）。我的理解是 coredata 检索该对象的所有项目，然后使用谓词过滤它们。这真的是它的工作原理，还是我误解了？如果它确实表现得像这样，这是否有效？c) 虽然我已经尽可能地扁平化了结构，但我仍然需要将 3 或 4 个表连接在一起——在核心数据中使用这样的关系是否有效？
我没有问题重新阅读 coredata 书籍然后应用它，如果它确实是这种场景的更好解决方案，只是我读过的所有书籍和示例都是 1 或 2 个具有单个关系的几个属性的实体. 我的数据库模式，所以我的 coredata 数据模型会比这复杂得多。另一个考虑因素是 - 与 sqllite 相比，核心数据在消耗休息服务或 JSON 以从服务器获取数据并将传输完成详细信息返回服务器方面是否提供任何优势？
请在下面查看我的经验：以防有人阅读这篇文章并想知道我作为 SQL Server/ASP.net 人员的经验....
我开始使用 SQLite，我发现它使用起来又快又容易。API 不是很好，但作为一个 SQL 人，这根本没有让我失望。
我能够通过对生成的脚本的小修改轻松地从 SQL Server 编写表结构脚本，让我很快就可以在 SQLite 中使用我的表结构
我开始在 asp.net 中访问，所以我对编写脚本和创建动态 SQL 字符串并不陌生。然而，我不再想使用这种方法，因为我觉得它已经过时了，所以虽然我使用 SQLite 检索数据可能有点矫枉过正，但我想将数据放入适当的对象中。我想创建对象数组并编辑对象的属性。它在目标 C 中对我来说更有意义。在 asp.net 中，我仍然不为我的数据创建对象，我使用 SQL Server 存储过程，因为我有一个非常复杂的数据结构，并且希望完全控制我查询的所有内容。
然而，创建用于包装表格的类需要 AGES数据表/实体/无论您喜欢如何称呼它们。
我在这里选择了核心数据。
您可能需要使用类别来扩展生成的类，但这实际上非常简单，而且非常酷，
coredata 的一大优势是 fetchedresults 控制器自动在表格视图中显示更改。因为我的应用程序有 2 或 3 个表视图，它们是分层的——比如在视图 2 中更改数据，然后返回到表视图、视图 1 并查看视图 1 中所做的更新，而无需手动重新加载数据非常酷。
谓词没问题。它们有足够的意义，请记住，无论您要获取什么对象，您都可以从该对象中横向关系-也很酷，如果有时有点混乱-我觉得这是一种完全倒退的 sql 思维方式。一旦你习惯了它，它就足够简单和强大了。一开始只是有点奇怪
NSManaged 对象（您存储在核心数据中的任何对象）及其子类都有自己的 managedobjectcontext - 即self.managedObjectContext轻松地显式保存任何更改，即：
self.name=@"james"
self.favouriteColour=@"blue"
NSError * error;
if ([self.managedObjectContext save:&error]) {
NSLog(@"saved");
}
这比必须设置 sqlite 连接、命令和执行它们等要干净得多。
核心数据 API 比 SQLite API 干净得多（它是 c）。
猜我是一个皈依者！