我已经开发了一个非常基本的核心数据应用程序超过一年了（Toy Collector，http://bit.ly/tocapp），我正在考虑重新设计，以便我可以构建iCloud支持。我想，在我这样做的时候，我不妨更新我的核心数据模型（如果需要的话），而且我有一段时间追踪以下的“最佳实践”：
目前，我有2个实体：
玩具，关键词
玩具具有关于对象的所有信息：名称，年份，集合，图像名称，拥有，通缉，制造商等，（共18个属性）
关键字有标准化的单词以帮助加快搜索速度
我的问题是，将一些玩具属性分解为自己的实体是否有任何好处。例如，我可以有一个制造商实体来存储十几个制造商，而不是将这些信息保存在Toy对象中。我的直觉告诉我这可以减少内存占用（而不是存储制造商字符串的50,000个对象，在与主要玩具实体有关系的实体中，简单地有12个制造商字符串）。这种组织真的很重要吗？我试图过度复杂化吗？我觉得我的实体有很多属性，我不确定是否花时间把它分成多个实体会有所作为。
任何建议或指示都将不胜感激！
扎克
答案 0 :(得分：2)
您的问题非常广泛，因为它涉及database design的主题。让我先说，几乎不可能给你任何明智的建议，因为我需要了解更多关于你的应用程序，用例等等，而不是通过S.O.问题
提出具体问题，我会说你正确地确定了将一个表分成多个表的优点之一;实际上，这样做的好处不仅仅是减少数据库占用空间，而是将data redundancy保持在最低限度。冗余不仅会影响内存占用，还会影响数据的可管理性和可修改性，缺乏冗余甚至可能导致异常或损坏。甚至有一个完整的数据库理论主题被称为database normalisation，它解决了这个关注的问题。
另一方面，总是如此，冗余可以帮助提高性能，而实际情况是，您可以通过简单查询而不是多个查询或表连接来获取数据。有一种提高数据库性能的技术，称为database denormalization，与规范化完全相反。您当前的方案已完全非规范化。
使用Core Data是一个关系对象图管理器，它经常运行在SQLite（一个关系数据库管理器）之上，你还要考虑到Core Data会自动构建你的对象图并获取内存这一事实。您需要时的数据。这意味着，如果您可以将磁盘上较小的内存占用视为理所当然，那么在查询结果的RAM占用空间时可能就不会出现这种情况（Core Data将会＃34;爆炸＆＃34;，所以说，在有时你的数据从多个表到一个对象加上它的属性。）
在您的特定情况下，您还应该考虑迁移现有用户群的成本（如果数据库不是只读的）。
总而言之，如果您的应用目前没有任何数据库占用问题，我会说如果您不认为创建新表可能有用，例如，为了添加新功能，例如列出所有制造商;最后，如果你没有预见到在某些时候重命名制造商等任务，那么重构数据库可能不会带来太多好处。但是，正如我所说，如果不详细了解你的应用程序和你的路线图，就很难在现场说出任何内容。无论如何，我希望这些一般性的考虑能帮助你做出决定。
编辑：
如果您想调查核心数据性能并尝试了解瓶颈所在，请尝试使用仪器/核心数据工具（产品/配置文件菜单）。有很多事情可能会变坏。
另一方面，如果没有关于您的应用允许执行的搜索类型的更多详细信息，真的很难帮助您。我不清楚的一件事是，只有当他们返回大量结果时你的搜索速度很慢，或者即使返回一些结果他们也很慢。
如果您仅使用（例如，在搜索之后）仅一个规范化实体（例如，在表格中显示玩具名称），则规范化可能有助于提高性能。在这种情况下，引用其他实体的所有属性都将是错误（因此不会占用内存也不会占用），这可能会加快速度。但是，如果你进行搜索然后显示其他表中的信息，那么可能没有任何优势，恰恰相反，因为必须立即解决故障，这将产生对数据库的更多访问。
确实，根据您的使用方式，核心数据可能不是处理数据的最佳方式。看看这个Brent Simmons' post relating his experience.