具有购物清单功能的配方应用程序数据库设计（iOS CoreData）

我正在开发一个菜谱应用程序，它将具有购物清单功能，我想知道这种方法是否正确

Recipe (one to many)
- title
- serving
- image meta
- ingredients
- steps
- note

Recipe Category (has many Recipe)
- main
- side
- ...

Shopping List (has many recipe ingredients)
- recipe[3].ingredients[2]
- recipe[5].ingredients[3]
- recipe[5].ingredients[4]
- ...

所以基本上，购物列表实体将引用配方实体中的成分。我知道最好将配料作为一个单独的实体，但由于用户可能以不一致的方式输入配料（有/没有数量），我选择将其作为配方实体的属性

我相信核心数据是某种形式的ORM，就像PHP中的条令一样，我见过许多用例，其中每个实体不一定都有id属性。在传统的关系数据库中，关系是建立在相互实体的id属性上的，但是核心数据似乎能够在不需要id的情况下建立关系

因此，我对购物清单实体的做法是，我将参考配方[3]和配料[4]等配料，我想知道这是一种可接受的做法，还是一种完全错误的思维方式

由于购物清单实体将是其他实体的纯引用，我甚至不知道是否需要一个实体。如果iPhone有某种本地存储，我可以用它来代替吗？这是不同的问题，但我只想知道保存购物清单记录的正确方法

更新

购物清单实体还应该存储用户将通过自定义字段添加的自定义项目。我想知道下图是否正确地建立了这种关系

---

将配料设置为独立对象，如下所示：

ID_1 = {title:"Tomato", x:y, p:k etc}
ID_2 = {title:"Bread"}
ID_3 = {title:"Cheese"}
ID_4 = {title:"Sugar"}

设置您的配方对象，如下所示：

ID_A = {ingredients:[ID_1, ID_2, ID_3], title:"Margherita", serving:2 }
ID_B = {ingredients:[ID_2, ID_3], title:"Cheese on Toast", serving:1 }
ID_C = {ingredients:[ID_4], title:"Caramel", serving:6 }

ID_k = {purchase:[ID_1,ID_2,ID_3,ID_4] timestamp:[NSDate date]}

ID_k = [{recipe:ID_A, ingredients:[ID_1,ID_2] timestamp:[NSDate date]},{}]

按如下方式设置您的购物清单：

ID_A = {ingredients:[ID_1, ID_2, ID_3], title:"Margherita", serving:2 }
ID_B = {ingredients:[ID_2, ID_3], title:"Cheese on Toast", serving:1 }
ID_C = {ingredients:[ID_4], title:"Caramel", serving:6 }

ID_k = {purchase:[ID_1,ID_2,ID_3,ID_4] timestamp:[NSDate date]}

ID_k = [{recipe:ID_A, ingredients:[ID_1,ID_2] timestamp:[NSDate date]},{}]

对于自定义配料（由用户输入），动态添加到配料数据库中，并以相同的方式引用，例如

ID_5 = {title:"Custom Ingredient"}

您已经了解了配方和成分之间的关系（以及这些成分可能具有的任何特征，如营养价值），以及购物清单和成分之间的关系

如果您需要将购物清单和食谱联系起来，或者如果您只想购买食谱中的某些成分，您可以这样做：

ID_A = {ingredients:[ID_1, ID_2, ID_3], title:"Margherita", serving:2 }
ID_B = {ingredients:[ID_2, ID_3], title:"Cheese on Toast", serving:1 }
ID_C = {ingredients:[ID_4], title:"Caramel", serving:6 }

ID_k = {purchase:[ID_1,ID_2,ID_3,ID_4] timestamp:[NSDate date]}

ID_k = [{recipe:ID_A, ingredients:[ID_1,ID_2] timestamp:[NSDate date]},{}]

更新

当用户开始输入配料时，例如“to”，对配料数据库进行字符串搜索并提出建议，例如“西红柿”。如果找不到现有条目，请允许用户添加自己的条目。这将减少冗余条目的数量

对于数量，向配料对象添加一个附加变量，例如

ID_1 = {title:"Tomato Puree", measurement:"liter"}
ID_2 = {title:"Bread", measurement:"gram"}
ID_3 = {title:"Cheese", measurement:"gram"}

在配方部分：

ID_A = {ingredients:[ID_1, ID_2, ID_3], quantity:[0.5, 200, 300], title:"Margherita", serving:2 }

在购物清单对象中：

ID_k [{recipe:ID_A, ingredients:[ID_1,ID_2], quantity:[2,300,200], timestamp:[NSDate date]}, {}]

当向用户显示数据时，您可以首先检查成分的测量类型，并用更易于阅读的字符串替换浮点值

---

例如，如果你的数量是“0.5”，你的测量值是“文字”（或类似的东西），你可以显示“一半”，或0.25是“四分之一”等。对于其他测量类型，例如“克”，只需直接显示数量和测量值，例如300克。

你的购物清单包括食谱，还有他们的配料数组中的一个值，对吗？如果你不必一次添加所有成分（例如，如果用户已经有了一些成分），我会按照你现在的方式添加。购买的物品[{id:x，时间戳：y，所有者：recipeX，成分：p}]我的购物清单将包含配方的成分，不一定是配方和用户可以添加的随机物品（自定义字段）。请看我的更新图。谢谢。将配料作为独立对象的唯一问题是，用户很可能会在有/没有单位数量的情况下随机输入不一致的条目，例如，

3个番茄、1/2汤匙糖、土豆、少量樱桃等。通过这种方式，很难捕获成分的唯一记录，并最终得到许多数量不等的冗余记录。我可以通过证明数量字段和配料名称来对用户输入设置一些限制，但在移动设备上填写许多小字段可能会让人不知所措，因此我将其设置为配方属性。我应该添加到上面更新的答案中，如果没有指定数量，则依赖默认值。但在任何情况下，您都可能必须在某个地方定义“少量”和某个度量值之间的关系。如果你看一看MyFitnessPal应用程序，你会发现他们正在努力解决这个问题，相同（或略有不同）成分的不同测量类型。谢谢你的努力。虽然我决定不把配料作为独立的对象，但你的洞察力让我重新思考了这个问题。我的应用程序的基本部分是让用户输入过程非常快，而不需要数量、单位等细节。它面向像我这样喜欢简单东西的用户。我已经开发了一个特殊的UI，它通过一个自由文本成分字段使输入过程变得简单，我想我应该保留它。谢谢没问题，祝你好运！我同意你说的，我们保持简单，有很多杂乱的用户界面。