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

Question

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

我最初的想法，我肯定是错误的，就是每个州有一个db。其中包括餐馆列表（以及地址，电话号码，评级等任何基本信息）。然后，每个餐厅我有一个db代表菜单。此数据库将包含定义每个菜单项的列。

这完全不合适吗？有没有更理想的方法来实现这一目标？我目前与Postgres一起玩的经历仅限于一个数据库。

我只是在寻找一个好的描述，而不是一堆代码。这更像是一个普遍的架构问题。提前谢谢！

Answer 1

我总是建议您先写下您想要存储在数据库中的所有单个内容，最多只需原子形式，这对您的应用程序有意义。

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

示例架构：

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

Answer 2

您的问题实际上是关于关系数据库设计，而不是Postgresql本身，因此您可以跟踪并了解这些内容。

您对第一个想法的描述是沿着正确的道路前进，除了不是单独的数据库，这些不同的实体应该存储在单独的表中。 （只有当你没有真正的可能性需要将这些项目相互比较，或者搜索所有这些项目等等时，你才会把事情分解成单独的数据库。在你的描述中，这些事情最好都在一个数据库。）