前篇回顾
在租车信息系统数据库设计(3)中我们实现了更为细致的车辆出入库管理。
本篇将试图解决剩下的2个问题:
1. 顾客对于租车费用的支付信息如何记录,顾客可以通过预先充值后消费的方式来支付(这也是区分会员级别的关键),该如何支持?
2. 我们在第一篇中暂时没考虑“送车上门和上门取车”服务,要支持这一功能,我们对数据库结构要做些什么改动?
1、支付管理
对于租车费用的支付,我想到了如下几个关键点:
1)顾客可以预先向会员卡充值,之后进行消费。
2)对于一个订单的费用,支付来源可以有多个。例如:订单总费用2500元,顾客选择先用完会员卡中的1000元,再刷卡1500元进行支付。
3)对于顾客的一次支付,可以对应多个Order。例如:顾客租用了2辆车,在我们的系统中会对应2个Order,顾客可以1次刷卡支付这2个Order的全部费用。
对于关键点1,我们要在系统中为每个顾客创建账户(Account),顾客向会员卡充值或使用会员卡消费都对于一笔流水(Transaction)。
对于关键点2、3,说明了订单与顾客支付之间是一种多对多关系。
我的解决方案如下:
1. 在原先的Table_Customer表中增加Customer_AccountBalance,Customer_AccountCurrency字段,存放顾客账户结余。需要注意的是这个字段的信息是可以通过累加该顾客所有的账户流水得到,有些冗余但能提高获取账户余额的性能。Customer_AccountBalance和账户流水之间是总账和明细账的关系,需要计划一些时间点进行结算(即总账与明细账轧平)。
2. 增加Table_AccountTransaction表,即账户流水表,顾客每次充值与支付都会在该表中增加一条记录。在本设计中,我把顾客支付某Order时的现场刷卡或付现金行为也作为该顾客对自己账户的先充值,之后再从顾客账户扣款支付Order。这种设计方式能减少表的数量、好理解,但所用的顾客刷卡或付现都进入到了总账,之后再与Order关联,无法很明确的得到顾客的某次刷卡是为了支付哪个特定的Order(你只能通过时间和金额来推测)。大家对此可以进行思考,给出解决方案,并比较优劣。
Table_AccountTransaction字段
列名 | 解释 |
AccountTransaction_ID | Identity字段 |
Customer_ID | 顾客ID,外键 |
AccountTransactionType_ID | 流水类型ID,外键 |
AccountTransaction_Date | 流水产生日期 |
AccountTransaction_Amount | 流水金额(正值为充值,负值为支付) |
AccountTransaction_ReferenceID | 参考号码 |