对于我的应用程序，我想到了两种不同的数据模型，但我看不出哪一种在性能和文件大小方面都是最好的。在我的应用程序中，我必须存储食谱，其中包含一个包含成分的数组，一个包含说明的数组，一个包含提示的数组和一些用于选择一些食谱的属性（例如评级，菜肴类型）。
我想到了两种不同的模型。第一种方法是将数组转换为NSData并将它们全部存储在Core Data模型中。由于阵列是本地化的，这意味着在那里将存在多个相同类型的阵列（例如instructionsEN，instructionsFR，instructionsNL）。由于没有必要查询数组，我很高兴我必须将数组转换为NSData。
另一个模型是核心数据，它只包含过滤配方的属性，以及存储在主包或文档目录中的.plist文件的标识符（因为其中一些文件将由我们，有些是由用户创建的）。这个.plist文件将包含所有指令，成分等。同样，对于不同的本地化，有多个相同类型的数组。
我希望你能帮助我决定哪些选项在性能和磁盘空间方面最佳。如果你能想到一个不同的解决方案，我也会很感激。
答案 0 :(得分：1)
如果您要使用Core Data，通常应该全力以赴。在这种情况下，您将拥有NSManagedObject成分。我可能会在像stringValueForLocale:这样的成分上加上一种方法来处理我最好的价值。这意味着给定的成分可以翻译一次，并且可以重复用于所有食谱。
然后，您将拥有一个具有成分，数量值和单位的组件实体。食谱将具有指向这些的1：M属性components。 Component也应该有一个englishDescription，它会返回一个可打印的值，如“1 / 4c sugar”，而frenchDescription可能会打印“50g de sucre”（请注意音量/质量转换）那里;组件可能就是你管理它的地方。）
说明略有不同，因为它们不太可能重复使用。我想你可能会很幸运，“把鸡蛋打到坚硬的山峰上”。可能会出现在几个食谱中，但除非你要积极寻找那些类型的重用，否则它可能比它的价值更麻烦。说明也是解决文化差异的自然场所。在法国，鸡蛋通常在室温下储存。在美国，他们总是冷藏。要将法国食谱正确地翻译成美式英语，您有时必须加入额外的步骤，例如“将鸡蛋带到室温”。 （但是这取决于配方，因为它并不总是无所谓。）它通常是有道理中的说明，而不是在配料做到这一点。
我可能会用Instructions创建一个stringValuesForLocale:实体（它会返回一个字符串数组）。然后，您可以进行一些分析，并决定是否将其分解为单独的LocalizedInstructions实体，这样您就不必为所有本地化做出错误。这种设计的优点是您可以稍后改变您对内部数据库布局的想法，并且它不会影响更高级别。但是，在任何一种情况下，我都可能将实际指令存储为编码NSArray的NSData。这可能不值得创建一堆单独的LocalizedInstruction实体的麻烦和成本。