求教 mysql 表设计

[kestrelBright]

就是用户签订购房合同，然后每月还款。 现在设计了有一个签的合同表，还有一个用户还款记录表。

需要搜索用户违约了几期，需要搜索某天有哪些用户违约。比如 1 号是 a 用户的还款日且未还款，那么搜 2 号 a 用户要出来，但是如果 b 用户已经违约，他还款日是 2 号，搜 2 号他不出来

现在想法是两种，一种是签订了合同就把还款记录生成好，实际还款时再更新；一种是每次还款都更新一个下期还款日期

但感觉都不大好，求大佬指教

[7911364440]

再建一张逾期表，通过定时任务每天统计有哪些用户未还款。
用户违约了几期？可以通过用户的还款日以及用户最新的还款记录计算出来。
某天有哪些用户违约？直接查逾期表

[jucelin]

第一种。第二种不好，考虑影响因素太多

[wxf666]

你是不知道怎么写 SQL 实现那俩搜索吗？

还是写了 SQL ，但速度太慢，问怎么提速？


要不放一下你当前的表结构和 SQL ？

[kestrelBright]

@7911364440 谢谢
@jucelin 谢谢

@wxf666 想找个好点的方案

[Maxwe11]

这种都是挺标准的金融信贷数据设计，都有成套的方案，做房贷的按理说你们那儿应该有对应懂产品的人；

一般的标准结构都分这么几个部分：
1 、用户系统，下属用户数据、扩展数据，征信数据，内部预授信数据，内部风控数据……
2 、进件系统，产品，内容、合同……
3 、信贷业务，细分里你说的那个部分，是结合产品、内容、合同和用户的数据，一般有还款计划表（就是贷款后要先把计划还款都列出来），实际还款（就是根据合同和实际还款行为的对应数据），一般的统计计算就是这几个数据和用户及合同这几个数据的联合；
4 、业务催收数据；

当然这里面还有各种配套的，什么卡 bin 、日期时间、息费规则、代收付配套接口等等等等等；

房贷业务你们还要自己写？？？

[nothingistrue]

两种都要有。第一种相当于将还款计划和还款历史这两个实体合并成一个实体，未尝不可，当然分成两个实体也可以，但是，还款计划这个数据是必须有的。第二种的数据，是以用户为维度的逾期情况，这个数据是很有必要存在的，不然你逾期提醒都不好做。

如果参考信用卡，你还需要一份数据，账单。当然你们要不是正规金融机构的话，还款计划、还款记录、账单，这三个可以合并成一个实体来处理。以用户为维度的逾期情况这个实体，就没法合并了，要合并它也是合并到用户实体上。

其实这个设计过程，跟数据库没关系。你得先设计好了这些实体关系，然后再去往数据库上映射。

[wxf666]

@kestrelBright 我觉得当前表结构，足够你用 SQL 实现那俩需求了

不知你说的『当前方案不够好』，是不好在哪儿


@7911364440 这个『逾期表』，是只能统计『当天』哪些用户违约，还是『任意一天』（楼主好像需要后者）

[xuelu520]

第一种，我看招行和京东白条，都是提前生成好每一期的金额

[lazyfighter]

第一种，第二种本身的业务逻辑依赖用户来驱动说是话方案有点扯

[setsunakute]

第一种,一般逾期还款都有状态标记, 查询起来也很方便

[BQsummer]

第一种万一要调整还款计划怎么吧, 删了重新生成? 不如晚上跑批, 落一个逾期表

[optional]

面向业务模型编程，而不是面向数据库编程，你的数据模型有状态变迁就通过 job 或者消息通知之类的方式完成状态迁移，而不是通过数据库延迟计算去满足。
这个例子就是，每日逾期，可以每天脚本计算。

[fuxinya]

每个月的出账日，即生成所有用户的当月账单，记录最后还款期限日。然后根据还款期限日查询即可

[zhaogaz]

都不对，你应该先设计业务模型，数据库层受业务模型约束，而不是先定义表结构，你弄反了。。

[golangLover]

@Maxwe11 求教这些方案 / 设计在哪里可以看到。谢谢

[cowcomic]

如果只是用来进行还款记录和逾期搜索，第一种就能满足，觉得不太好的原因是还有别的业务吗？

[xuanbg]

客户是客户，合同是合同，计划是计划，履约是履约。这些数据都是独立的，也是通过业务相关联的。

[Maxwe11]

@golangLover 关键词 [信贷系统+开源] ，随便找几个，在测试服务器上部署下，看看后台表结构借鉴一下就行了。

[kestrelBright]

谢谢各位大佬