MYSQL食品订购门户数据库设计

Question

我试图为一个餐馆订购门户创建一个数据库，我已经创建了不包括支付表的表。我有点纠结于它是否是正确的结构。如果我能得到任何反馈，这将是非常感谢！因此，数据库应该允许以下内容：

• 允许客户订购
• 餐厅可更新/添加菜单
• 餐厅可以确认/拒绝订单。

(我还没有添加“小猴子”或“飞碟”)

CREATE TABLE Customer (
customerID INT(11) NOT NULL,
Fname VARCHAR(100) NOT NULL,
Lname VARCHAR(100) NOT NULL,
email VARCHAR(255) NOT NULL,
phone INT(14) NOT NULL,
address VARCHAR(255) NOT NULL,
postcode VARCHAR(20) NOT NULL

CREATE TABLE CusOrder (
orderID INT(11) NOT NULL,
prodname VARCHAR(55) NOT NULL,
quantity INT(11) NOT NULL,
price FLOAT(10 , 2 ) NOT NULL,
totalprice FLOAT(10 , 2 ) NOT NULL,
menuID INT(11) NOT NULL,
deliveryfee FLOAT(10 , 2 ) NOT NULL,
customerID INT(11) NOT NULL

CREATE TABLE resturantMenu (
menuID INT(11) NOT NULL,
deliveryfee FLOAT(10 , 2 ) NOT NULL,
productName VARCHAR(255) NOT NULL,
productPrice FLOAT(10 , 2 ) NOT NULL

CREATE TABLE resturantLogin (
resturantUserID INT(11) NOT NULL,
menuID INT(11) NOT NULL,
username VARCHAR(255) NOT NULL,
pass VARCHAR(255) NOT NULL,
restDetails VARCHAR(255) NOT NULL,
restPhone INT(14) NOT NULL,
restAddress VARCHAR(255) NOT NULL,
restPostcode VARCHAR(20) NOT NULL

CREATE TABLE orderConfirm (
orderID INT(11) NOT NULL,
resturantUserID INT(11) NOT NULL,
status ENUM('yes','no') NOT NULL

不要害怕批评，所以请开火:)

Answer 1

第一:不要编码，抽签。在图中犯错误比在代码中尝试可视化关系、键等容易得多。在这一点上，在设计列类型是无关的。键和关系的Focus。

这可能是一个良好的起点*：

在这里，我们有顾客可以为餐馆下订单。这些订单不能包含那家餐馆没有提供的商品。这些订单可以包括相同的项目，以不同的价格(购买1，得到1.5%的折扣，等等)。这些订单可以包括费用，包括可以从时间表中查询的送货费。

图中未回答的问题：

1. 如何确定OrderLine是菜单项还是收费，并强制执行？
2. 如何定义Order的状态？
3. 究竟是什么包含了OrderLineCharge？
4. 订单是否应该请求一个菜单项/数量，然后成为一个OrderLine？
5. 当MenuItem被请求但无法实现时，会发生什么？
6. 价格变化是如何储存的？
7. 我们应该跟踪菜式还是菜品类别？
8. 如何跟踪送货？
9. 如何跟踪付款？
10. 我们如何跟踪数量折扣(每个2美元，3美元5美元，等等)？
11. 是OrderId还是OrderNumber？

这是很多我们不会用代码或表定义来解决的问题，至少现在还没有。

接下来我建议的步骤是：

1. 熟悉ERD，特别是易于阅读和理解的IDEF1X。
2. 开始思考业务规则以及它们如何塑造您的数据模型--您可以通过约束/关系来解决哪些问题？哪些问题将要求事务包含规则？

*我遗漏了很多，因为这不是一步一步就能解决的问题--我不知道这是作业作业、业余爱好项目还是实际工作。