目录
1.客户模块(注册的只能是客户,其他的内部人员需要管理员自行添加)
根据分析可知,内部人员是无法直接通过注册进行添加的,同时也不建议用户注册之后再修改权限。综合后,再新建一张表【员工表】:
客户还需要点单,还需要设计一个【订单表】(客户使用多选框进行点单)
食材不够时,需要记录一下信息,同时将这些信息添加到一个表里面【缺失食材信息表】:
对账单信息进行保存,也就是说当仓库处理完采购的订单之后,还需要再在自己这边做一次备份,同时加上账单保存的时间【账单信息表】:
相关模块以及对应的数据库的设计
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.客户模块:
客户登录之后,会通过列表展示所有的菜品