假设我有一个关于 cooking 食谱的应用程序，它具有两个基本功能:
标准场景
我当前的食谱是“芝士蛋糕”，在
RecipeDetailViewController中，我可以看到为该食谱添加的当前食材:好吧，假设我对最终结果感到满意，然后决定保存(记录)我刚准备的食谱。
* 单击保存 *
现在，该食谱已保存(现已记录)，并且在
RecipesHistoryViewController中，我可以看到类似以下内容:现在，如果需要，我可以编辑历史记录中的食谱，然后将Milk更改为Soy Milk。
问题是在历史记录中编辑配方应该不要在我当前的配方中编辑配方(及其成分)，反之亦然。如果我编辑当前食谱并将黄油替换为花生酱，则它不能编辑历史记录中存储的任何食谱。希望我自己解释一下。
结果
这种情况意味着什么？表示当前，为了满足此功能的功能，每次用户单击“保存配方”按钮时，我都会复制配方和每个子关系(成分)。很好，但是我觉得可以再干净一点。有了这个实现，事实证明我有如下这样的TONS:不同的重复Core Data对象(sqlite行):
等等。
有想法吗？如何优化此模型结构？
编辑1
我已经考虑过使用属性
NSString创建任何 RecipeHistory 对象，可以在其中存储json字典，但是我不知道它是否更好。编辑2
当前，
RecipeHistory对象包含以下内容:+-- RecipeHistory --+
| |
| attributes: |
| - date |
+-------------------+
| relationships: |
| - recipes |
+-------------------+
+----- Recipe ------+
| relationships: |
| - recipeInfo |
| - recipeshistory |
| - ingredients |
+-------------------+
+-- RecipeInfo ----+
| |
| attributes: |
| - name |
+-------------------+
+--- Ingredient ----+
| |
| attributes: |
| - name |
+-------------------+
| relationships: |
| - recipe |
+-------------------+
paulrehkugler说的对，当我创建一个
Recipe时复制每个RecipeHistory对象(及其关系RecipeInfo和Ingredients)会使数据库充满大量数据时，他是对的，但我找不到其他解决方案，该解决方案可以为我的 future 提供灵活性。也许将来我会创建有关配方和历史记录的统计信息，并且拥有Core Data对象可能会很有用。你怎么看？我认为这在许多存储历史记录并允许编辑历史记录的应用程序中都是常见的情况。大更新
我已经阅读了一些用户的答案，并且想更好地解释这种情况。
我上面提到的示例只是一个示例，我的意思是我的应用程序不涉及Cook/Recipe参数，但我使用了食谱，因为我认为对于我的实际情况而言还可以。
说了这一点，我想解释一下该应用程序需要两个部分:
-第一:我可以在这里看到带有相关成分的当前食谱
-第二:点击第一部分中的“保存食谱”按钮，可以看到我决定保存的食谱
在第一部分中找到的当前配方和在“历史记录”部分中找到的X配方没有共同点。但是，用户可以编辑“历史记录”部分中保存的任何食谱(他可以编辑名称，配料，所需内容，也可以完全编辑“历史记录”部分中找到的有关食谱的所有内容)。
这就是为什么我要复制所有
NSManagedObject的原因。但是，通过这种方式，数据库将变得疯狂，因为每次用户保存当前食谱时，代表该食谱的对象(Recipe)都会被复制，并且食谱具有的关系也将被复制。因此，将有许多吨名为“黄油”的成分。你可以对我说:为什么你需要拥有大量的“黄油”物体？好吧，我需要它，因为配料具有例如“数量”属性，因此每个食谱都具有不同数量的配料。无论如何，我都不喜欢这种方法，即使它似乎是唯一的一种。问我您想要什么，我将尽力解释每一个细节。
PS:对不起，我的基本英语。
编辑
最佳答案
由于您必须处理历史，并且由于事件是由最终用户手动生成的，因此请考虑更改方法:与其存储模型实体的当前 View (即配方，配料以及它们之间的联系)，不如存储已启动的各个事件。由用户。这称为Event Sourcing。
这个想法是记录用户的行为，而不是记录用户操作后的新状态。当您需要获取当前状态时，请“重放”事件，并将更改应用于内存结构。除了让您实现即时需求之外，这还使您可以通过“重播”特定日期之前的事件来还原特定日期的状态。这有助于审核。
您可以通过定义以下事件来做到这一点:
CreateIngredient-添加新成分，并为其赋予唯一的ID。 UpdateIngredient-更改现有成分的属性。 DeleteIngredient-从当前状态删除成分。删除成分会将其从所有配方和配方历史记录中删除。 CreateRecipe-添加新配方，并为其指定唯一的ID。 UpdateRecipeAttribute-更改现有配方的属性。 AddIngredientToRecipe-将成分添加到现有配方中。 DeleteIngredientFromRecipe-从现有配方中删除一种成分。 DeleteRecipe-删除配方。 CreateRecipeHistory-从特定配方创建新配方历史记录，并为该历史记录提供新的ID。 UpdateRecipeHistoryAttribute-更新特定配方历史记录的属性。 AddIngredientToRecipeHistory-将成分添加到配方历史记录中。 DeleteIngredientFromRecipeHistory-从配方历史记录中删除一种成分。 您可以使用Core Data API将单个事件存储在单个表中。添加一个按顺序处理事件的类，并创建模型的当前状态。事件将来自两个地方-由Core Data支持的事件存储，以及来自用户界面的事件。这样一来，您可以保留一个事件处理器和一个带有配方，配料和配方历史记录当前状态详细信息的模型。
Replaying the events should happen only when the user consults the history, right?
不，不是这样的:您将启动时的全部历史记录读入当前的“ View ”中，然后将新事件发送到 View 和数据库中以实现持久性。
当用户需要查阅历史记录时(具体来说，当他们需要找出模型在过去的特定日期的外观时)，您需要部分重播事件，直到感兴趣的日期为止。
由于事件是手工生成的，因此不会有太多事件:我最多估计成千上万的计数-这是100种配方的 list ，每种配方有10种成分。在现代硬件上处理事件的时间应以毫秒为单位，因此读取和重放整个事件日志的时间应以毫秒为单位。
Furthermore, do you know any link that shows an example of how to use Event Sourcing in a Core Data application? [...] For example, should I need to get rid of RecipeHistory NSManagedObject?
我不知道在iOS上进行事件来源的良好引用实现。这与在其他系统上实现它没什么不同。您将需要摆脱当前拥有的所有表，而将其替换为一个如下所示的表:
这些属性如下:
EventId-此事件的唯一ID。这是在插入时自动分配的，并且永远不会更改。 EntityId-此事件创建或修改的实体的唯一ID。该ID由Create...处理器自动分配，并且永远不会更改。 EventType-表示此事件类型名称的短字符串。 EventTime-事件发生的时间。 EventData-事件的序列化表示形式-可以是二进制或文本形式。 最后一项可以替换为一组“非规范化”列，这些列代表上述12种事件类型使用的属性的超集。这完全取决于您-该表只是存储事件的一种可能方式。它不一定是核心数据-实际上，它甚至不必位于数据库中(尽管它使事情变得容易一些)。
关于ios - 核心数据模型设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19992593/