配置表是表里最容易理解且不易出錯的表了，主要設計時注意了范式。這種表以只讀為主，一般數據設定好就不會多次改變。這里不需贅述。
流水表一般和狀態表成對出現，用戶余額是一種常見易於理解的狀態表：
| 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日--