我该如何组织一个Postgres数据库以获取餐馆及其菜单项目列表？

Question

我在玩Postgres并试图解决更复杂的问题。想象一下，在美国的50个州中，每个州都有一大批餐馆。每家餐厅都有一个菜单，每个菜单都包含一组包含价格，描述等内容的项目。什么是组织数据的好方法？

我最初的想法，我敢肯定是错的，那就是每个状态都有一个db。在那里将是一个餐馆列表（以及任何基本的细节，如地址，电话号码，评级等）。然后，我会有一个代表菜单的餐厅。这个数据库将包含定义每个菜单条目的列。

这完全不合格吗？有没有更理想的方法来完成这一点？我目前与Postgres一起玩的经验仅限于一个数据库。

我只是在寻找一个很好的描述，而不是一堆代码。这更多的是一个通用的建筑问题。提前致谢！

Answer 1

我总是建议你先写下你想要存储在数据库中的所有单独的东西，最多原子形式这对你的应用程序有意义。

在这个例子中，我假设它是一家特许经营餐厅，并且你想跟踪它的各种商店和他们的产品。

样本模式：

1. 一种成分表，可以列可能是：
   • 名称
   • 供应商
2. 一个菜单项表，可以列可能是：
   • 名称
   • Descirption
   • 是素食主义者
   • 具有坚果
   • 是犹太
3. 链接，其成分菜单项的表：
   • MenuItemPK
   • IngredientItemPK
4. 一每个餐厅的桌子：
   • 名称
   • 所有者
   • 联系信息
5. 一种每家餐厅的位置表：
   • RestaurantPK
   • 分行名称
   • 市
   • 国家
   • ZIP
   • 营业时间
6. 链接，其菜单餐厅的表：
   • RestaurantLocationPK
   • 菜单名称（例如， '周末的晚餐'）
   • 菜单Descirption
7. 将菜单链接到其项目的表格：
   • MenuItemPK
   • MenuPK

Answer 2

你的问题实际上是关于关系数据库设计，不PostgreSQL的本身，所以这东西给你追踪和了解。

你对你的第一个想法的描述是朝着正确的道路前进，除了不是单独的数据库，而是将这些不同的实体存储在单独的表中。（只有在没有必要将项目与其他数据库进行比较或搜索所有项目等情况时，才会将事情分解成单独的数据库。在描述中，这些内容都最好一个数据库）。