假设我有一个关于烹饪食谱的应用程序,它具有两个基本功能:
- 第一个涉及我正在准备的当前食谱
- 第二个存储我决定保存的食谱
标准场景
我目前的食谱是“芝士蛋糕”,RecipeDetailViewController
我可以看到我为这个食谱添加的当前成分:
- 糖
- 牛奶
- 黄油
- 等等
好吧,假设我对最终结果感到满意,我决定保存(记录)我刚刚准备的食谱。
*点击保存*
配方现在已保存(现已记录),RecipesHistoryViewController
我可以看到如下内容:
- 2013 年 11 月 15 日 - 芝士蛋糕
- 2013 年 11 月 11 日 - 布朗尼
- 等等
现在,如果我愿意,我可以编辑历史记录中的食谱并将牛奶更改为豆浆,例如。
问题是在历史记录中编辑食谱不应该在我当前的食谱中编辑食谱(及其成分),反之亦然。如果我编辑当前配方并用花生酱替换黄油,则不得编辑历史中存储的任何配方。希望我自己解释。
结果
这个场景意味着什么?暗示目前,为了满足此功能的功能,每次用户单击“保存配方”按钮时,我都会复制配方和每个子关系(成分)。好吧,它有效,但我觉得它可以是其他更干净的东西。通过这种实现,我发现我有大量不同的重复核心数据对象(sqlite 行),如下所示:
- 对象 #1,名称:黄油,配方:1
- 对象 #2,名称:黄油,配方:4
- 对象 #3,名称:黄油,配方:3
等等
想法?如何优化此模型结构?
编辑 1
我已经考虑过创建任何带有属性的RecipeHistory对象NSString
,我可以在其中存储 json 字典,但我不知道它是否更好。
编辑 2
目前一个RecipeHistory
对象包含这个:
+-- RecipeHistory --+
| |
| attributes: |
| - date |
+-------------------+
| relationships: |
| - recipes |
+-------------------+
+----- Recipe ------+
| relationships: |
| - recipeInfo |
| - recipeshistory |
| - ingredients |
+-------------------+
+-- RecipeInfo ----+
| |
| attributes: |
| - name |
+-------------------+
+--- Ingredient ----+
| |
| attributes: |
| - name |
+-------------------+
| relationships: |
| - recipe |
+-------------------+
paulrehkugler 说,Recipe
当我创建一个对象时复制每个对象(及其关系 RecipeInfo 和成分)RecipeHistory
会用大量数据填充数据库,但我没有找到另一个解决方案来让我在未来具有灵活性。也许将来我会创建关于食谱和历史的统计数据,并且拥有 Core Data 对象可能会被证明是有用的。你怎么看?我认为这是存储历史记录并允许编辑历史记录项的许多应用程序中的常见场景。
大更新
我已经阅读了一些用户的答案,我想更好地解释这种情况。我上面提到的示例只是一个示例,我的意思是我的应用程序不涉及烹饪/食谱参数,但我使用了食谱,因为我认为这对于我的真实场景来说还不错。
说到这里,我想解释一下该应用程序需要两个部分:-第一:我可以在其中看到包含相关成分的当前食谱-第二:我可以在其中看到我决定通过点击第一个按钮“保存食谱”来保存的食谱部分
在第一部分找到的当前配方和在“历史”部分找到的 X 配方没有任何共同之处。然而,用户可以编辑保存在“历史”部分中的任何食谱(他可以编辑名称、成分,无论他想要什么,他都可以完全编辑关于历史部分中找到的食谱的所有内容)。
这就是我想复制所有NSManagedObject
s 的原因。但是,通过这种方式,数据库将变得疯狂,因为每次用户保存当前配方时,表示配方 ( Recipe
) 的对象以及配方之间的关系(成分)都会被复制。例如,会有大量名为“黄油”的成分。你可以说我:为什么你需要大量的“黄油”物体?好吧,我需要它,因为配料具有例如“数量”属性,所以每个食谱都有不同数量的配料。
无论如何,我不喜欢这种方法,即使它似乎是唯一的一种。你想问我什么,我会尽力解释每一个细节。
PS:对不起我的基本英语。
编辑