PostgreSQL多语言菜谱数据库设计方案咨询

核心问题解决：菜谱热量筛选 #

• 预存营养汇总数据：鉴于菜谱总量仅1万条，完全可以在添加菜谱时预先计算并存储总热量、总蛋白质等核心营养指标。新增recipe_nutrition表，结构如下：
  recipe_nutrition(recipe_id, total_calories, total_protein, total_fat, total_carbohydrate)
  后续直接通过total_calories字段即可快速完成热量筛选，无需每次查询都关联食材表计算，性能提升明显。
• 实时计算备选方案：若不想预存数据，利用SQL聚合函数实时计算也可行——通过关联recipe_ingredient和ingredient表，执行SUM(ingredient.calories * recipe_ingredient.quantity)即可得到菜谱总热量，1万条数据量下不会有性能瓶颈。

多语言支持优化 #

• 拆分多语言字段到独立翻译表：将菜谱名称、描述、步骤等需多语言展示的内容从主表抽离：
  • recipe主表仅存核心非语言相关数据：id, created_at, creator_id
  • 新增recipe_translation表：id, recipe_id, language_code, title, description, step_text
    食材的多语言支持同理，用ingredient_translation表存储不同语言的食材名称、描述，新增语言时仅需添加翻译记录，无需修改主表结构。

购物清单与膳食计划关联设计 #

• 强化食材实体的累加逻辑：保留食材独立实体的设计，购物清单可分为两张表：
  • shopping_list：id, user_id, plan_date
  • shopping_list_item：id, shopping_list_id, ingredient_id, total_quantity, is_purchased
    生成购物清单时，通过关联膳食计划的菜谱，按ingredient_id做GROUP BY并SUM用量，即可实现食材数量累加，逻辑可在应用层或SQL层实现。
• 膳食计划关联表设计：meal_plan表关联user_id、recipe_id、meal_type（早餐/午餐/晚餐）、plan_date，清晰记录用户每日膳食安排，也为批量生成购物清单提供数据来源。

扩展性与性能优化建议 #

• 索引优化：
  • 给recipe_nutrition(recipe_id, total_calories)加联合索引，加速热量筛选查询。
  • 给recipe_translation(recipe_id, language_code)加联合索引，快速获取指定语言的菜谱内容。
  • 给shopping_list_item(ingredient_id)加索引，提升食材数量累加的查询效率。
• 数据量适配：1万条菜谱无需分库分表，后续若扩展至百万级，可考虑按菜谱分类或创建时间分表。
• 缓存策略：将热门菜谱的营养数据、多语言内容存入缓存（如Redis），减少数据库查询次数，提升响应速度。
• 维护便利性：由于仅你负责添加菜谱，可在后台添加流程中自动触发营养计算，同步更新recipe_nutrition表，避免手动维护的繁琐。

内容的提问来源于stack exchange，提问作者Just A Question