一个餐厅 菜的账单数据库该怎么设计

遵循数据库设计的第三范式即可

餐厅表：餐厅编号 餐厅名称 餐厅地址 餐厅老板

菜系表：菜系id 菜系类型 菜系描述

菜单表：菜谱id，菜谱系列 ，菜谱特色

关联一下就可以了

你做的是C-C的网站，也就是客户对客户的，数据库的设计相对也就麻烦一些。不过你们既是学生，也不用过于严谨，一般符合数据库三大范式前两个就行了。

首先你要明确自己要做什么，接着就是画出E-R图（实体关系图），E-R图画出来，数据库基本上就出来了。以我自己多年的开发经验，你们的项目最少需要十来张表，用户的信息（登陆、注册）就要两张，还有订单表也要两张，其他的用户发布的交易

首先来说对于这种场景有两种设计方法，这两种方法都能够满足扩展性要求

1. 把原有的横表转化为纵表存储属性，即

产品表：（product_id, product_name, product_class)

产品属性表：(product_id, property_id , property_name , property_value)

2. 保持原有横表设计思路，但是d性字段含义单独元数据表存储

产品表：（product_id, product_name, product_class, prop1, prop2, .... propn)

产品属性含义元数据表

(product_class , prop1_name ,prop2_name, ..... propn_name)

对于两种设计方法，个人理解为

a. 对于首页打开就必须要能够快速查询出来的属性，而且这些属性本身各类产品差异不大。而对于差异大的属性基本都是针对特定一个产品查询。可以采用方案1来做。

b. 首页显示产品列表时候就存在要显示出不同产品属性情况，采用方案2来做。当我们处理的是一个product list的时候，由于存在数据表本身的关联场景，用方案1会比麻烦，也影响性能。

---