新型数字钱包（现代基线）
使用场景: 构建纯数字银行的金融科技团队
Customer 含 kyc_status 和证件引用
Account 极简——通常每个客户一个钱包
Transaction 总是产生两条 LedgerEntry
Card 由卡组织合作伙伴（Visa/Mastercard）签发
无实体 Branch——用 Issuer 引用替代
这样组织的原因: 新型数字银行把 schema 精简到核心——每客户一钱包加干净的复式账本。图表去掉分行换成合作伙伴引用，因为客户从不到访。
银行 / 金融数据库 Schema 示例
以下银行 schema 示例展示了同样的客户-账户-账本核心如何适配新型数字钱包、传统核心银行系统、借贷平台和支付处理商。
真实案例
传统核心银行
使用场景: 运营多种账户类型和渠道的银行
Branch 作为面对面银行的一等实体
多种 AccountType：活期、储蓄、货币市场、定期存单
利息计提表与 AccountType 利率连接
柜员和 ATM 取款产生交易
客户可持有多种不同类型的账户
这样组织的原因: 传统核心银行携带更多产品多样性——图表保留 Branch 并扩展 AccountType，因为同一客户持有活期 + 储蓄 + 定期，各有不同利率和行为。
借贷平台
使用场景: 构建消费或中小企业借贷产品的团队
Loan (principal, interest_rate, term_months, status)
Repayment 表带计划 vs 实际还款
Customer 上有信用分和 KYC 字段
放款是一笔贷记 Account 的 Transaction
每次还款是一笔含两条 LedgerEntry 的 Transaction
这样组织的原因: 借贷把 Loan 和 Repayment 放在核心——图表的资金移动仍用复式账本，放款和还款各自产生标准的 Transaction 行。
支付处理商
使用场景: 构建 Stripe 式支付产品的团队
Merchant (id, business_info, payout_account_id)
Payment (id, merchant_id, customer_id, amount, status)
结算批次汇总每日付款用于日结
退款和拒付表关联到原始付款
费率结构作为按商户的定价规则建模
这样组织的原因: 支付处理商的 schema 以 Merchant 和 Payment 为中心——图表把客户重构为端点（付款方/收款方）并加入结算批次，因为产品在各方间移动资金，而非持有存款。
使用技巧
- 始终用 Transaction + LedgerEntry（复式）建模资金移动；单条「转账」行隐藏错误并破坏审计。
- 把 Account 余额存为去规范化缓存，但要与 LedgerEntry 之和对账——账本才是真相。
- 把 KYC 状态和证件引用放在 Customer 上；合规审计要求易于查询。
- 用 account_no 作为外部标识与代理 id 分开——账号面向客户且不可变，id 是内部的。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=banking-fintech-database-schema
编辑此银行 schema 模板