如何设计这个 RDBMS 模式？
因此，我们的食物通常是一个单元，而食谱则由不同数量的不同食物组成。
我们想要跟踪一些基本信息，例如价格和营养信息。
我们如何为此设计 RDBMS 模式？
所以，这可能是最明显的解决方案：
[Foods] : ID, Name, Carbs, Protein, Fat, Price
[RecipeIngredients] : ID, FoodID, RecipeID, AmountOfFood
[Recipes] : ID, Name
但是，由于食谱几乎具有与食物相同的操作，因此我需要创建大量重复的代码来支持两者。
这是另一种方法：
[Foods] : ID, Name, Carbs, Protein, Fat, Price, IsRecipe
[RecipeFoods] : ID, FoodID, RecipeID (which points to another Food), AmountOfFood
现在所有操作对两者都相同。但是，仅添加特定于食品或食谱的字段会为其他实体创建空列。
你会如何解决这个问题？你更喜欢哪一个？有更好的办法吗？
So we have foods, which are usually of one single unit and recipes, which consist of varying amount of different foods.
We want to track a few basic things like the price and the nutrition info.
How would we design RDBMS schema for this?
So, here is the probably most obvious solution:
[Foods] : ID, Name, Carbs, Protein, Fat, Price
[RecipeIngredients] : ID, FoodID, RecipeID, AmountOfFood
[Recipes] : ID, Name
However, since recipe has almost all the same actions as foods, I need to create a lot of duplicate code to support both.
Here is another approach:
[Foods] : ID, Name, Carbs, Protein, Fat, Price, IsRecipe
[RecipeFoods] : ID, FoodID, RecipeID (which points to another Food), AmountOfFood
Now all the actions work same for both. However, adding fields only specific to Food or Recipe creates empty columns for the other entity.
How would you solve this? Which one do you prefer? Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
保持数据库规范化。
正如您已经注意到的那样，
Recipe不是Food，因此他们不应该共享一张桌子。每个实体在数据库中都应该有自己的表。
Keep your database normalized.
A
Recipeis not aFoodas you had already noticed, so they shouldn't share a table.Each entity should have its own table in the database.
如果您必须具有此数据库结构（+1 到 Oded），请确保未使用的列为 NULL 并且您的代码可以处理此问题。
If you must have this database structure (+1 to Oded), make sure the unused columns are NULL and that your code handles this.