厨房菜篮子系统的设计与实现

目录

相关模块以及对应的数据库的设计

1.客户模块（注册的只能是客户，其他的内部人员需要管理员自行添加）

数据库设计【客户表】：

根据分析可知，内部人员是无法直接通过注册进行添加的，同时也不建议用户注册之后再修改权限。综合后，再新建一张表【员工表】：

客户还需要点单，还需要设计一个【订单表】（客户使用多选框进行点单）

同时，根据此处的场景，还需要再设计一张【客户反馈表】：

    2.厨师

数据库设计【菜品表】：

食材不够时，需要记录一下信息，同时将这些信息添加到一个表里面【缺失食材信息表】：

3.采购

数据库设计【采购食材表】：

4.仓库

数据库设计【食材表】：

对账单信息进行保存，也就是说当仓库处理完采购的订单之后，还需要再在自己这边做一次备份，同时加上账单保存的时间【账单信息表】：

5.超管（商家）

6.登录页面

---

相关模块以及对应的数据库的设计

1.客户模块（注册的只能是客户，其他的内部人员需要管理员自行添加）

    客户登录之后直接显示可以点的菜品列表（当菜品食材数量不够时【食材不够，不能制作出菜品】，菜品置灰）
    客户可以进行点菜（相当于给厨师提交“订单”）
    客户可以进行反馈（相当于对菜品进行打分）【单独设一个反馈表，记录每次的反馈】
    客户余额显示（提交“订单”时随即扣除相应的余额）

数据库设计【客户表user】：

字段设计：

用户id（user_id）（会员号），用户名（name），用户密码（pwd），注册日期（register_date），用户余额（balance），已消费总额（expenditure），用户等级（vip_grade）（当消费累积到一定的金额，可以提升用户等级，根据相应的等级，可享有一定的折扣），用户权限（power）（根据这个来确认登录后的页面），备用字段1（memo1），备用字段2（memo2）

根据分析可知，内部人员是无法直接通过注册进行添加的，同时也不建议用户注册之后再修改权限。综合后，再新建一张表【员工表emp】：

字段设计：

员工id（emp_id）（工号），员工名（name），员工密码（pwd），入职日期（entry_date），员工权限（power），备用字段1（memo1），备用字段2（memo2）

客户还需要点单，还需要设计一个【订单表orders】（客户使用多选框进行点单）

字段设计：

订单id（order_id），客户id（user_id），订单内容（主）（first_content）（显示效果”菜品id+‘-’+菜品id+‘-’+菜品id“），订单内容（次【起显示作用】）（second_content）（显示效果“菜品名称+‘-’+菜品名称+'-'+菜品名称”），产生金额（money），生成时间（gen_date），是否处理（is_doing）（这个字段是由厨师来修改的）（当厨师接到订单并开始处理之后，相应的系统会自动扣除对应客户的余额，同时也会自动减去菜品所涉及的食材的数量），备用字段1（memo1），备用字段2（memo2）

同时，根据此处的场景，还需要再设计一张【客户反馈表feedback】：

字段设计：

反馈id（feedback_id），用户id（user_id），用户名（name），反馈内容（content），是否处理（is_doing）（客户看不到反馈处理的结果，这个字段是给商家看的，商家自行决定处不处理（这个反馈就相当于一个建议，而不是命令）），反馈生成时间（generate_date），备用字段1（memo1），备用字段2（memo2）

    
2.厨师

    菜品出菜（对客户的“订单”进行处理），出菜之后相应的减少食材数量
    菜品信息（显示每一种菜需要的食材数量）
    【取消这个，这个通过系统自动反馈比较好】食材不够时反馈给外购人员（也就是相当于给采购提交“订单”）

数据库设计【菜品表menu】：

字段设计：

菜品id（menu_id），菜品名称（name），菜品价格（price），涉及食材（related_material）（显示效果“食材id+‘-’+食材id+'-'+食材id"，设计使用多选框进行食材的添加），菜品生成日期（generate_date），备用字段1（memo1），备用字段2（memo2）

如何知道食材不够？？？（当所剩食材不能满足所有菜品足额制作2次时，可以算作是缺少食材，相应地定位到缺少的食材。计算过程：以所有菜品所分别涉及的食材的乘以2为一个红线，当有任何一个食材数量低于这个红线时，系统会自动对采购发出提示信息）

食材不够时，需要记录一下信息，同时将这些信息添加到一个表里面【缺失食材信息表food】：

字段设计：

食材id（food_id），食材名称（name），所缺数量（count），是否处理（is_doing）（这个字段是由采购来修改的），备用字段1（memo1），备用字段2（memo2）

因为厨师还需要对客户的订单信息进行处理，还需要在厨师的界面添加一个显示所有未处理的订单的列表，厨师可以对这些订单进行处理

3.采购

    食材的采购（对厨师的“订单”进行处理）
    购买之后需要对购买的“账单信息”进行保存
    账单信息保存之后，再告诉仓库（也就是对仓库提交“订单”）

数据库设计【采购食材表buyfood】：

字段设计：

采购的食材id（buyfood_id），采购的食材名称（name），采购的食材价格（price），采购的食材数量（count），是否处理（is_doing）（这个字段是由仓管来修改的），备用字段1（memo1），备用字段2（memo2）

因为采购还需要对缺少食材的提示信息进行处理，同样的需要在采购界面添加一个显示所有未处理的订单的列表，采购可以对这些订单进行处理，处理之后，系统自动对仓库发出提示信息（表示已经采购好，当仓库管理登录时对信息进行处理【类似于游戏里面收到邮件一样】，仓库收到食材后，系统会自动更新仓库里面的食材的数量），如果仓库管理不及时处理，那么食材就会以”邮件“的形式累积起来，必须要仓库确认之后才能入库，入库之后才能更新食材数量

4.仓库

    对采购的账单信息进行确认（对采购的“订单”进行处理）之后就存入仓库
    然后对账单信息进行保存

数据库设计（这个是仓库的食材展示）【食材表】：

字段设计

食材id（buyfood2_id），食材名称（name），食材价格（price），食材数量（count），备用字段1（memo1），备用字段2（memo2）

对账单信息进行保存，也就是说当仓库处理完采购的订单之后，还需要再在自己这边做一次备份，同时加上账单保存的时间【账单信息表】：

字段设计

采购的食材id（buyfood3_id），采购的食材名称（name），采购的食材价格（price），采购的食材数量（count），处理日期（doing_date），备用字段1（memo1），备用字段2（memo2）

5.超管（商家）

    收集客户的反馈信息
    根据客户的反馈信息对菜品进行改良或是上新
    可以上架新菜品（菜品包含所需的各种食材的数量），同时设置该菜品的价格

这边可以显示用户的反馈

可以上架菜品，和厨师共用菜品表（只不过厨师没有对菜品进行操作的权限，而商家有）

6.登录页面

    这个设计系统自动判断

正式开发

1.登录页面：

登陆页面有注册选项，注册默认只能注册客户，内部员工无法通过前台注册来添加，需要管理员后台注册添加

登录之后系统会自动判断用户的权限，并根据用户的权限自动跳转到相对应的页面，登录之后将相关信息保存到session里面

2.客户模块：

客户登录之后，会通过列表展示所有的菜品