配置表是表里最容易理解且不易出错的表了，主要设计时注意了范式。这种表以只读为主，一般数据设定好就不会多次改变。这里不需赘述。
流水表一般和状态表成对出现，用户余额是一种常见易于理解的状态表：
| ID | UID | Balance |
| id | 用户id | 用户余额 |
| 1 | 001(张三) | 1800 |
| 2 | 002(李四) | 3000 |
| .. | ... | ... |
| N | 250(尼古拉斯赵四) | 18000 |
有了这张表，取某人的资金余额就容易了，如果表大了要快速，可以给id，uid，balance加上联合主键。
当然这种表还要配合一个流水表，或者叫履历表或台账表，要不搞鬼就太容易了，连核对都无从对起。流水表类似这样：
| ID | UID | Action | ctime |
| 1 | 250 | -1000 | 2020-1-15 |
| 2 | 250 | -2500 | 2020-1-16 |
| 3 | 001 | +3000 | 2020-2-1 |
| .. | |||
| N | 250 | +18000 | 2020-2-10 |
这样，要知道尼古拉斯赵四的钱怎么来怎么去的，看流水表就知道了。为了保证事务，还得状态表和流水表在一个session里操作。另外，流水表的更新时间utime字段如果会被用来查找最新记录，必须要逐条更新而不是批量更新，否则会找出多条，给后继处理带来麻烦，另外还需注意时间的精度要足够，不能只到秒级别。
其实这样将表按业务分类挺清晰的，但由于各种原因(主要是设计者没有分表思想，主要以实用主义原则进行设计及行政力强制推行方案)，实际中使用的表经常集三种表的功能于一身，比如到流水表中去统计余额，到状态表里用distinct找配置，状态表中的值不是配置表中的外键，结果是SQL写得晦涩，查询冗长还不好优化，程序运行慢且卡，让人唏嘘不已。
--2020年2月16日--