现在，大到银行等金额机构，小到城市一卡通，直到餐馆等路边小店的会员系统都在使用电子支付进行结算。

 

根据系统应用的用户规模和交易量，系统的数据库设计也是不同的。

 

那种账户一年才几个，交易量不到一万笔，交易额在10万以下的小系统，用个access就能解决，感觉不用特别去研究。

 

那种超大规模的应用，如股票交易、信用卡结算，涉及到问题太多，一两句说不清楚。

 

这里主要说说，我们平时接触到的大多是一些中小型的结算系统，如连锁商场的会员卡储值系统，校园餐卡系统，加油站，网站在线交易等。

 

 

1. 数据库设计的原则

1) 准确记录账户基本信息，特别是状态。

2) 交易时要正确记录下交易信息和账户状态。

3) 交易记录是历史性的，不可篡改。

4) 交易是连续的，对时间要求准确。

5) 交易记录要完整，对安全性有要求。

 

 

 

2.主要数据表

1) 账户基本信息表

    记录账户的持有人姓名、联络方式、余额、有效期、密码、流通范围等。为了安全，该表还应该由账户、姓名、有效期和余额组成的检验串，防止有人恶意修改余额或账号。

2) 交易记录表

    记录每一笔交易信息，除了记录交易账户、交易时间、交易金额、交易后余额和交易内容（充值或消费购物）外，还应该记录下账户的其它基本信息，如账户持有人姓名、交易地点等。这也许会增加数据的存储量，但这是有必要的。如在银行储藏点存下钱，这个储藏点若干年后，可能更名、关闭等，在此之后要查当初在这个点的交易时，就可能会用到初交易时的信息。

     另外，交易记录不建立使用太多的代码表示特定意思，一是时间太久了会看不明白代码是什么意思，二是代码可能被重复使用。

     所有交易必须有数据完整性校验，即一行记录一旦生成后其校验串也就固定了，防止有人恶意修改记录行的值。

3) 账户变更记录表

    由于账户基本信息是可变更的，基于交易系统的交易记录的历史性和档案性，所以对账户基本信息的任何变更都必须有记录，由什么变更为什么，一定要有记录，否则以后一旦查历史，找不到当初变更的信息就麻烦了。

4) 操作日志明细表

    所有的操作必须有详细的日志记录。

 

3.技巧

1) 应当根据应用的规模进行合理设计，如交易量非常大（每天超过10万笔）那就需要考虑创建分区表，如果更大，就要考虑建立历史交易表或交易库，即把一年或几年前的数据独立出来，仅供特殊需要时查询。

2) 建立索引，如按日期、账户建立索引，可以加快查询速度。

3) 建立报表数据存储表，即在报表生成之后，就把生成的结果数据保存下来，以后再要进直接进行查询，不要每次都根据原始表进行统计。

4) 适当提高硬件配置是比较划算的。

 

 

4.其它

1) 一定要考虑扩展性，主要在应用地区范围、时间范围、用户（消费者）、客户（商家）方面。

2) 应急的处理，如备份、分布式（不同地方设立数据库）的独立运行、离线等。

3) 要有开放的思想，想想在未来如何方便其它系统、成员、合作伙伴也可以加入进来。

4) 安全是非常重要的，即使是数据库管理员也不要留给其作恶的机会。

5) 数据库建立自我监测机制，发现异常发出警示和锁定账户。

 

 

仅个人想法，请多指点。

阅读更多

更多精彩内容