设计我的第一个数据库模式：需要建议

Question

这是我的第一个数据库架构设计。我正在尝试为我的部门开发一个小型Web应用程序，用于食品成本管理。我这样做是出于学习目的。

食品成本管理如何在我的部门工作：

1. 总成员：15
2. 一位管理员记录所有费用。他将每天更新数据库。
3. 每位会员每天只能订购一次。如果有人在任何特定日期有客人，他可以订购多份餐点。
4. 通常会员提前一两周支付账单。
5. 一个或两个人负责从外面带食物，他们不需要支付午餐费用。运输成本也给他们。他们的食品成本+运输成本平均分配给其他15名成员。

数据库查询：

从管理角度来看：

1. 他将管理/添加每日订单。 （表：订单）
2. 他将为所有会员添加付款，这笔款项将记入各会员的“余额”（表：付款）
3. 他将能够在一张图表中查看所有会员的订单/费用历史记录及其当前余额的概览，每次一个月。
4. 如果任何会员的余额为负数或少于特定金额，则会通知管理员信息中心。

从会员角度来看：

1. 他将能够一次查看他目前的余额和订单/成本历史记录。
2. 他将能够看到他所做的最后x个付款记录。

根据我上面提到的查询，我尝试设计一个数据库模式，如下图所示：



详细阐述一些属性：

EPlatenum ：除了订购的板数之外还带来了额外的食物盘数。

Eplatecost ：额外食物的成本。这笔费用在15个人的个人费用中平均分配。

EPersonnum ＆amp; EPersoncost ：参与食物的额外人数及其总费用。费用将在15个人的个人费用中平均分配。

TransCost ：运输成本。费用将在15个人的个人费用中平均分配。

问题：

1. 我犯了哪些错误，如何克服错误？

2. 对于我的DailyList表，我使用“date”作为主键。是否可以使用date作为主键？如果不行，那么这里的主键是什么呢？

3. 当我要填充30个月成本/订单历史记录的图表概述时，我假设数据库查询将是巨大的。我应该采取什么方法来优化查询？

我期待收到有关改进数据库架构的建议。请帮助我纠正我的设计错误并克服它们。感谢您的耐心等待。

Answer 1

我的第一印象：

1. 我认为付款应与订单相关（因为用户需要支付特定订单）。
2. 我不知道DailyList是什么，但是如果可能有两个以上的日期相同（并且我可以成像），则不应将其用作主键。
3. 密码应使用例如SHA（所以varchar 15更少）。