1. 信贷系统模型表整体设计思路1.1 这件事的核心难点在哪信贷系统的数据模型设计说难不难说简单也不简单。我见过太多团队业务刚起步的时候拍脑袋建了三四张表等业务规模上来之后发现扩展一个产品类型要改一堆代码加一个风控字段要动五六张表的结构最后只能靠一堆临时表和中间表硬撑。这种痛苦经历过的人应该都能体会。信贷系统模型表的核心难点不在于“建表”而在于三个字前瞻性。所谓前瞻性就是你要在业务只有一种产品、一天几百笔进件的时候预见到未来可能有三五条产品线、每天几十万笔进件你的表结构是否还能撑得住。不能撑得住后面就是持续两三年的重构痛苦能撑得住后面的事情都会顺很多。第二个难点在于状态机的设计。信贷业务是一条长链路进件、审批、授信、签约、放款、还款、结清、逾期、催收、核销、呆账。每个环节都有状态状态之间还有流转关系。状态设计得不好后续所有统计报表都会乱掉。比如一个“逾期”状态在不同产品里含义可能不同——消费贷逾期1天和房贷逾期1天严重程度完全不一样但如果你设计表的时候不把“逾期天数段”拆出来后续就容易出问题。第三个难点在于金额字段的精度处理。钱这个东西一分钱都不能出错。但是信贷业务日息、罚息、复利、提前结清、部分还款各种金融计算混杂在一起数据库浮点数精度不够整数存储又不够直观到底怎么存才稳妥这是每个做信贷系统的开发都必须想清楚的问题。第四个难点在于多租户隔离与数据视角。如果是做助贷平台、多资金方接入、联合贷那么你的模型表还需要考虑资金方维度、渠道方维度的隔离。同一个客户在多个资金方各有额度和借据怎么区分、怎么汇总这也是一个隐藏的深坑。1.2 模型表的核心实体关系梳理在信贷系统里核心实体其实就那么几个。我们先不看具体字段先把主干捞出来。客户、申请单进件、授信额度、合同、借据/放款记录、还款计划、还款流水、逾期记录、催收记录。这是信贷系统最底层的九张表其他所有表都是围绕它们延展的。客户表管“谁在借钱”申请单表管“每次申请的情况”授信额度表管“给客户批了多少钱、还能借多少”合同表管“双方约定”借据表管“实际放了多少出去”还款计划表管“每一期该还多少”还款流水表管“客户实际还了多少”逾期记录表管“哪些款项到期没还”催收记录表管“为了追回欠款做了什么”。这九个实体之间的关系我通常这么描述一个客户可以发起多笔申请一笔申请经过审批通过后会生成一个或多个授信额度。额度之下客户可以发起提款每次提款生成一笔合同合同项下会生成借据。借据会展开为多期还款计划客户每期还款时会产生还款流水。如果某期计划到期未还系统会生成逾期记录逾期记录会驱动催收工单。这就是信贷系统的主干数据流。你在做模型设计的时候第一步不是去想字段怎么设计、索引怎么设计而是把这九张表之间的关系理顺确保业务流转过程中产生的每一份数据都能在这套骨架中找到合理的位置。任何游离在骨架之外的“特殊需求”基本都说明骨架设计有问题。1.3 为什么强调“宽表不如窄表”在设计信贷模型表的时候很多刚入行的同学倾向于设计宽表——把所有相关字段堆在一张表里省去关联查询看起来“性能好”实际后面会哭。举个真实例子。我们之前接过一个系统客户信息表里有三十多个字段包括职业、单位名称、单位电话、单位地址、身份证有效期、婚姻状况、学历、车辆信息、房产信息、联系人A、联系人B等等加上客户的基础身份信息一张表七十多个字段。当时设计的人说“这样查询快不用join”结果后面业务方提需求说“联系人信息需要支持多联系人录入每天户最多支持五个紧急联系人”改表结构就改了一天还影响到了业务主流程的性能。信贷系统的模型表设计语义边界比物理存储更重要。客户基本信息是一层客户扩展信息职业、资产、联系人是一层客户风险标签是一层客户关系如关联企业又是一层。永远不要嫌表多你要做的语义隔离是为了将来任何一层发生变化时其他层不受牵连。我建议所有做信贷系统的同学在设计模型表时把“核心表”和“扩展表”分开把“高频查询字段”和“低频异常字段”分开把“强一致数据”和“弱一致数据”分开这样后面无论是做数据迁移还是做性能优化都轻松得多。2. 核心表结构与字段设计的实操拆解2.1 客户信息表唯一客户标识怎么设计客户信息表是整个信贷系统的基石。这个表设计得好不好直接决定了后续所有业务流程的顺畅程度。先说说唯一客户标识。很多系统直接拿“身份证号”作为客户的唯一标识看起来好像没问题——每个人身份证号是唯一的。但实际业务里并非如此同一个客户可能在线上渠道注册了一个账号又在线下门店提交过资料两个渠道录入信息时身份证号写法有差异一个带X一个带x一个15位一个18位或者客户的手机号变了就可能被当成两个客户。如果你用身份证号做唯一标识后面做额度合并、客户去重会非常痛苦。我建议的做法是客户表有自己的主键ID同时单独加一个“客户唯一标识”字段用于关联身份信息主键ID自增即可客户唯一标识则是业务上用来做客户归并的聚合键。在唯一标识的生成层面身份证号可以参与拼装但不要直接把它当唯一键。还有一个字段值得专门提出客户状态。这个状态至少要有“正常、冻结、注销、黑名单”四种。黑名单客户如果后续被解禁需要保留历史标记所以“是否黑名单”建议不要简单用一个布尔值而是用“黑名单状态 黑名单原因 最近拉黑时间”这样给后续风控策略留了余地。客户表的索引设计也要用点心思。身份证号是必查字段手机号是高频查询字段建议都以身份证号作为前缀索引建唯一索引通常是身份证号加姓名防冲突手机号建普通索引。如果做过分库分表这类的索引规则还要再重新设计这里就不展开了。2.2 进件申请单表多产品复用的关键进件申请单表也叫申请件/申请单/借款申请是信贷系统里交易量最大的一张表之一。每天进入的贷款申请都会在申请单表里产生一条记录。很多系统把申请单表设计成了“一个产品一张表”消费贷申请一张表经营贷申请一张表房贷申请一张表。这样做虽然直观但后续的问题很多第一业务方提一个“查询客户所有申请记录”的需求你要跨三张表去union第二新产品上线时你得再建一张几乎一模一样的表第三风控策略要读取所有申请做风险分析时数据来源分散做特征加工的成本很高。我在实际项目里的做法是一张主申请单表 多张产品扩展表。主申请单表只放所有产品通用的字段申请单号、客户ID、申请时间、产品编码、申请金额、申请期限、审批状态、审批人、审批时间、进件渠道、归属机构ID等。而各个产品特有的字段——比如房贷的房屋估值、首付比例、按揭年限或者车贷的车辆VIN码、车辆评估价、车龄等——则放到对应的产品扩展表中用申请单ID关联。这样做的好处非常明显。主表的查询性能不会被产品特有字段拖累产品特有数据在各自的扩展表里独立管理。你后续要加一个新产品的特有字段只需要新增一张扩展表不动主表结构影响面被缩到最小。关于申请单状态我在这里多强调一句。申请单一定要有完整的审批状态流转至少包含草稿、待初审、初审通过、初审拒绝、待终审、终审通过、终审拒绝、已撤销、已失效这几个核心状态。如果一个申请单被驳回后重新提交建议不要修改原申请单状态为“重新提交”而是生成一个“申请版本号”同一个申请单号下维护多条申请版本这样追溯日志就不会乱。2.3 审批决策表把人工经验和规则模型分开审批环节是信贷业务的核心风险控制点审批数据值得单独建表——审批决策表。审批决策表记录每一次审批动作的详细结果包括审批单ID、审批节点、审批人、审批结果通过/拒绝/人工复核、审批意见、审批额度、审批期限、审批利率、决策使用的策略集编码、命中规则明细JSON、评分卡得分等等。这里的一个关键点是人工审批数据和自动决策数据不能混在一张表里。人工审批关注的是审批人、审批时间、审批意见、审批照片等操作信息自动决策关注的是规则命中情况、模型评分、策略版本等算法信息。如果把两者混在一张表里后续做审批质量分析、策略回测、模型迭代评估时很难拆开使用。我的实操做法是审批主表 审批规则命中明细表。审批主表记录决策结果和审批人的信息审批规则命中明细表专门记录命中了哪条规则、规则版本、输出评分等。这样既保留了结果数据也保留了过程数据对后续模型迭代特别有价值。还有一个容易被忽略的字段审批时长。从申请单进入审批队列到审批完成之间的时间差是系统运营的重要考核指标也能反映审批效率变化趋势。别小看这个字段后面做客服投诉分析、审批流程优化都要用到它。2.4 授信额度表额度是信贷的“水龙头”授信额度表管理的是客户在系统中的总借款能力信贷额度相关设计细节比较多值得单独展开。额度表常见字段包括额度ID、客户ID、产品编码、额度类型单笔额度/循环额度、总额度、已用额度、剩余额度、生效日期、失效日期、额度状态。在多产品场景下一个客户可能在多个产品下各有一个额度所以客户对产品非唯一设计时要有“编码”概念。额度与授信审批高度的关系是审批通过后生成额度记录额度记录关联审批决策表。同时额度需要锁定机制——客户发起借款时先锁定额度放款成功后再扣除额度并释放锁定。这套并发控制逻辑对防止超额放款特别重要。我见过不少系统在额度扣除环节只是简单地在应用层查一下剩余额度然后做减法结果就是并发场景下额度超发实际放款总额超过了审批额度。正确的做法是在数据库层面通过对额度记录进行行级锁更新如使用select ... for update或通过update语句中的条件校验配合乐观锁版本号确保额度扣减的原子性。额度还必须有“恢复机制”。比如一笔借款提前结清后如果产品支持循环额度那么已用额度要能自动恢复。这个恢复操作一般通过还款流水事件触发而不是通过定时任务批量扫描。事件驱动的方式实时性好实现上也不复杂——只需要在结清回调里调用额度恢复服务即可。2.5 合同表和借据表签了字和出了钱是两回事合同表和借据表很容易被混为一谈但在信贷系统里这两者的业务含义完全不同。合同是双方权利义务的约定代表借贷关系的法律基础签约动作发生之后借贷关系即被确认。借据是放款凭证代表资金实际已经划拨出去。一次签约合同可以在额度内分多次放款所以一笔合同下可以有多张借据。合同表字段包括合同ID、合同编号、客户ID、产品编码、授信额度ID、合同金额、期限、利率模式固定/浮动、还款方式等额本息/等额本金/先息后本/一次性还本付息、合同签署时间、合同生效时间、合同状态生效中/已结清/已作废/已终止等。借据表的字段包括借据ID、借据编号、合同ID、客户ID、放款金额、放款时间、起息日、到期日、还款方式、期数、放款账户信息、资金方ID等。注意借据才是还款计划表的上游来源。每一张借据会展开成多期还款计划。这里有一个实操细节需要提醒扣款账户信息建议不要直接存银行卡号明文。可以存脱敏卡号加支付通道的令牌号这样即使数据库被拖库也不会造成大面积卡号泄露安全合规上能少很多麻烦。3. 还款计划、还款流水与资金清算明细3.1 还款计划表把钱怎么还的时间表说清楚还款计划表是按期生成的。每一张借据放款成功后系统会根据还款方式计算出每一期的应还日期、应还本金、应还利息、应还总额。这里以最常见的等额本息为例说一下计算公式每月还款额为( M P \times r \times (1r)^n / ((1r)^n - 1) )其中P是贷款本金r是月利率n是还款期数。比如借款12000元期限12个月月利率0.8%。代入计算每月月供约1052.76元。第一期利息为12000×0.8%96元本金部分为1052.76-96956.76元剩余本金变为12000-956.7611043.24元。第二期利息就变成11043.24×0.8%88.35元本金部分为1052.76-88.35964.41元。这样逐期递推最后一期本金刚好归零。每一期还款计划都应是一个独立记录字段包括还款计划ID、借据ID、期次、应还日期应还本金、应还利息、应还总额、逾期状态、实际还款日期、实还总额、结清状态。计算利息和本金分摊时务必用“分”为单位做整数计算或者用高精度的Decimal类型在关系数据库里可用numeric/decimal字段定义足够的精度避免浮点数误差累积。别小看这一条等额本息120期之后误差可能已经有好几块钱了。3.2 还款流水表每一分钱都从哪来到哪去还款流水表是粒度最细的账务数据表记录了每一笔资金划转动作。它比还款计划表更底层一件还款计划可以有多笔还款流水比如客户先还了一部分过两天又还了一部分。还款流水表核心字段包括流水ID、借据ID、还款计划ID可空、客户ID、交易时间、交易金额、本金部分、利息部分、罚息部分、违约金部分、还款方式主动还款/系统代扣/线下补录、支付渠道、支付流水号、交易状态。设计这张表的时候最难的不是字段而是如何保证对账的一致性问题。支付回调、渠道通知、手动补录多通道写入很容易出现同一笔还款被记两次或者漏记的情况。实操中的建议是还款流水表必须建立“业务唯一索引”通常用支付渠道流水号加还款计划ID作为联合唯一键。所有还款流水写入之前先按这个唯一键insert如果冲突就说明重复直接拒掉。这是最朴素也最有效的幂等控制手段。还有一点容易踩坑还款流水到账后业务系统需要更新还款计划的状态、更新借据的剩余本息、更新额度的已用金额。这三个更新要么全成功要么全失败建议用本地事务确保数据强一致。不要用定时任务去扫流水反推那样会造成对账延迟和状态回写的错乱。3.3 逾期记录与催收工单表风险处理链路逾期记录表和催收工单表严格来说属于贷后管理域。很多设计者在最初的模型规划中不重视这块直到坏账来了才开始补救结果非常被动。逾期记录的生成逻辑一般有两种一种是还款计划到期当天未还清系统跑批生成逾期记录另一种是还款日当天只还了一部分生成部分逾期记录。部分逾期是特别容易被忽略的尤其是按揭类的还款客户这个月只还了一半另一半逾期了逾期金额怎么算、罚息怎么计都要在逾期记录表里体现清楚。逾期记录表字段包括逾期ID、借据ID、还款计划ID、逾期本金、逾期利息、罚息、违约金、逾期开始日期、逾期天数、逾期等级M1/M2/M3等、结清时间。逾期等级不同公司有不同定义常见的是M1代表逾期1-30天M2代表31-60天M3代表61-90天M4代表更严重阶段。催收工单表是逾期记录的后续驱动表一般有工单ID、逾期记录ID、催收员ID、催收状态、催收计划时间、最近联系结果、承诺还款日期实还金额等字段。催收工单要与提醒记录分离一次工单会伴随多次电话提醒、短信提醒等动作这些提醒记录同样值得单独成表。催收话术、催收依据、客户承诺等文本信息可以放在扩展表里保持工单主表的简洁。4. 系统扩展域与附件管理4.1 影像资料表和合同附件表别让文件成为孤岛信贷系统里除了结构化数据还有大量的非结构化数据——身份证照片、人脸识别照片、收入证明、银行流水、合同扫描件、签章影像、电子签名等。这些文件如果管理不当很容易成为数据孤岛后续审计、合规、法律纠纷处理都很麻烦。统一的存储方案是影像资料表 物理文件存储文件服务器或云对象存储。影像资料表字段包括影像ID、业务类型进件/合同/贷后、关联业务ID、文件类型、文件名称、存储路径、OSS-Key、文件大小、上传人、上传时间。这样做的好处有以下几点。第一文件本身和业务数据解耦文件存储扩容不影响数据库性能。第二多业务可以共用同一套影像管理服务录入、查询、权限控制都有统一的逻辑。第三后续做档案电子化、合规检查时能够按业务ID和文件类型快速检索到全部文件。这里要补充一个教训关联业务ID不要存多值。我看到有些系统因为一张进件单有多张身份证影像就在业务表里存了一个“影像编号列表”用逗号分隔然后查询时又要用FIND_IN_SET之类的函数去拆。这其实违背了关系数据库的基本设计原则而且后续统计、归档、权限判断都非常痛苦。正确做法是影像表和业务表之间是多对一的关系影像表里存关联业务ID不要反过来在业务表里存影像ID列表。4.2 数据字典表和通用配置表让模型表“活”起来信贷系统涉及的枚举值非常多。产品类型、还款方式、客户风险等级、申请渠道、合同状态、借据状态、逾期等级、催收状态……这些枚举值不能硬编码在应用代码里而要放在数据字典表中做统一管理。数据字典表字段一般包括字典类型、字典编码、字典名称、状态、排序号、扩展信息。比如字典类型为“loan_product_type”字典编码为“housing_loan”字典名称为“住房贷款”。所有业务表里使用编码值展示时通过字典翻译成可读文本。这样做的最大价值在于新增一种产品类型或状态只需要在字典表里加一条数据不需要改代码、发版。通用配置表则用于维护业务参数比如最低还款金额、罚息利率、合同模板编号、代扣批次时间等。配置表字段包括配置键、配置值、配置描述、生效时间、失效时间。把业务参数和代码逻辑分开之后业务方自行调整参数而不需要开发介入对运营效率的提升不是一星半点。有些团队会把数据字典表设计成“一张大表所有类型都往里塞”比如dict_typeVARCHAR100dict_codeVARCHAR100dict_nameVARCHAR200这种结构。这样设计没有问题但要特别注意查询性能所有业务对字典表的访问量都很高字典表本身的数量也不小可能有几千条因此一定要建好联合索引dict_typedict_code并考虑如何做缓存——在应用层可以把字典表整体加载到本地缓存或Redis里过期策略十分钟足够这样查询字典时根本不走数据库大大缓解数据库压力。5. 模型表的落地实施要点与常见问题5.1 SQL建表示例与通用字段约定为了让大家能形象地感知模型表的落地实施效果我以九张核心链路中的“借据表”和“还款计划表”为例写两段极简DDL展示常见的字段与注释约定。CREATE TABLE loan_receipt ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键ID, receipt_no VARCHAR(64) NOT NULL COMMENT 借据编号, contract_no VARCHAR(64) NOT NULL COMMENT 关联合同编号, customer_id BIGINT NOT NULL COMMENT 客户ID, product_code VARCHAR(32) NOT NULL COMMENT 产品编码, loan_amount DECIMAL(14,2) NOT NULL COMMENT 放款金额单位元注意精度, loan_date DATETIME NOT NULL COMMENT 放款日期, value_date DATE NOT NULL COMMENT 起息日, maturity_date DATE NOT NULL COMMENT 到期日, repay_method VARCHAR(20) NOT NULL COMMENT 还款方式, status TINYINT NOT NULL COMMENT 借据状态0-正常 1-逾期 2-结清 3-核销, PRIMARY KEY (id), UNIQUE KEY uniq_receipt_no (receipt_no), KEY idx_customer_id (customer_id), KEY idx_contract_no (contract_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT借据表;CREATE TABLE loan_repay_plan ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键ID, receipt_id BIGINT NOT NULL COMMENT 借据ID, period_no INT NOT NULL COMMENT 期次, due_date DATE NOT NULL COMMENT 应还日期, due_principal DECIMAL(14,2) NOT NULL COMMENT 应还本金, due_interest DECIMAL(14,2) NOT NULL COMMENT 应还利息, due_total DECIMAL(14,2) NOT NULL COMMENT 应还总额, remain_principal DECIMAL(14,2) NOT NULL COMMENT 剩余本金, repay_status TINYINT NOT NULL COMMENT 0-未还 1-部分还款 2-结清, PRIMARY KEY (id), UNIQUE KEY uniq_receipt_period (receipt_id, period_no), KEY idx_due_date (due_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT还款计划表;关于列类型我做几点补充说明。金额字段一律用DECIMAL不用FLOAT和DOUBLE避免精度误差。货币单位建议统一为“元”在代码里全部以元为单位进行计算但特别注意小数精度控制必要时考虑在展示层做四舍五入加工。日期字段一律用DATE日期或DATETIME日期时间不做区分时不要混用。合理选择这两个类型关系到后续跟资金方系统进行对账的兼容性。主键统一用BIGINT自增。如果后续要分库分表全局ID生成策略再说但在单体阶段自增主键足够用。每一个表都要有“创建时间”和“更新时间”字段。这不仅是规矩而且后面排数据问题的时候没有这两个字段简直寸步难行。5.2 状态机流转是模型表的“灵魂”前面我多次提到了状态这里集中展开一下状态机设计。信贷系统的核心域中每个核心对象都有状态机状态机设计得好不好直接决定了业务流程的可靠性与可追溯性。这里以“借据状态机”举个例子。借据初始状态为“正常”。到期未还清系统跑批将状态更新为“逾期”同时生成逾期记录。客户还清逾期本息后状态恢复为“正常”对应的逾期记录也要关联上“结清时间”。当借据所有期次全部结清后状态更新为“结清”。如果出现了极端坏账通过核销流程将状态更新为“核销”。状态机设计要遵循两个原则每个状态的变更都要有触发事件每个状态变更都要记录操作日志。触发事件就是业务上的实际动作还款、跑批、人工操作等操作日志则记录变更前状态、变更后状态、操作人、操作时间、触发事件类型。没有日志的状态变更不可追溯后续处理客诉、审计都会是灾难。另外还有一点状态变更不一定要实时同步。比如借据从“正常”变为“逾期”一般是通过每日批处理任务来完成而不是每笔还款失败就立即改状态。一方面跑批处理效率高另一方面也避免小额短时波动对系统造成不必要的压力。但是像“还款成功”导致借据状态变为“结清”这类关键事件则要求实时同步因为客户端需要立即看到结果。你需要区分哪些状态变更可以异步批量处理、哪些必须同步实时更新。这个分寸把握是靠经验拿捏出来的。5.3 常见问题与排查技巧实录信贷系统上线跑了一段时间后常见问题逐渐暴露出来这里分享几个我实际遇到过、排查过的问题。问题一对账不平还款流水比账实金额多排查思路先比对还款流水表中的渠道流水号是否存在重复然后检查“支付回调”与“人工补录”是否走了同一个幂等校验逻辑。最常见的原因是人工补录时没有走系统唯一键校验补录了和自动还款同一渠道同一时间的流水。解决办法人工补录入口强制走同一幂等逻辑并把“业务来源”字段设为必填。问题二额度扣减偶尔超发排查思路检查扣减额度是否是在事务内完成是否对额度记录执行了行级锁。很多超发的原因是应用层先查额度、再更新额度两步之间发生了并发。解决办法改为单条UPDATE loan_limit SET used_amount used_amount #{amount} WHERE id #{id} AND used_amount #{amount} total_amount利用行锁和条件约束来保证并发安全。问题三逾期记录的重复生成排查思路检查逾期跑批任务是否做了幂等。有时是调度系统重复触发了跑批而跑批的逻辑里只判断了“当前日期等于还款计划应还日期”没有判断“逾期记录是否已存在”。解决办法在还款计划ID和逾期状态上建联合唯一索引从数据库层面拦截重复生成。问题四还清逾期款项后额度没有恢复排查思路检查还款流水事件是否驱动了“逾期结清”和“额度恢复”两个操作。常见原因是事件发送成功但消费端处理失败而且没有重试机制。解决办法还款清分时把“额度恢复”作为并发任务执行设置MQ消费失败重试重型重试不行走本地定时任务扫描补偿。这些问题的共性规律是信贷系统的异常大多不是发生在大流量并发下而是发生在补偿逻辑、边界条件和幂等控制缺失时。所以做模型表设计、接口开发时提前理清补偿路径比追求极致的性能更能省心。5.4 模型表设计中的字段冗余与性能平衡最后我们再回到设计层面谈一个几乎每个做信贷模型设计的同学都会纠结的问题字段冗余到底允许不允许比如客户表里存了一个“客户总授信额度”的汇总字段业务方查询时直接读取不用实时计算。这是字段冗余但它带来的好处是极大的查询性能提升。而如果客户表里存了“最近一次借款产品”这样的字段它也是冗余字段但这个冗余字段伴随高频率更新每个客户借款后都要改一次单看写入代价不大但客户量上来了之后代价就很明显。我个人总结的经验是三点。第一高频查询字段可以冗余高频更新字段不要冗余。第二冗余字段必须设计同步更新机制而且这个机制要尽量简单能在事务内完成的就不做异步。第三统计汇总类字段尽量放到宽表或数仓层不要塞进在线交易的核心表里。交易核心表越轻越稳统计分析的需求尽量通过数仓去满足。信贷模型表的“轻重分离”是一个长期工程。初期你怎么省事怎么来但一旦规模上了就不太可能回头了。所以模型表设计这个事我始终建议宁可前期多想一点点也别等上线之后再做“性能优化式重构”那时候的成本是前期的好几倍而且风险极高。这个内容后续还可以这样扩展细到具体场景去设计反欺诈特征表、人行征信报文解析与落库模型、额度策略引擎的决策表这些都是信贷系统模型表之上很自然的延展方向。真有兴趣的同行可以从这几类表开始深入研究一步步把信贷系统中数据底座的完整版图铺开。