文件表

文件表基础的字段就不说了。说几个我觉得很重要的字段：
1、数据状态字段：1、标识有效的数据；0、无效的数据。在网站上传文件的接口中，除了保存文件以外，还要添加文件表的数据，并把这条数据置为0无效。因为上传完以后还可能存在删除重新传的情况。所以直接设置为无效，后续的业务处理中再把数据修改为有效即可。
2、其他业务表id字段。通过这一字段就可以不用在创建“文件业务关系表”。优化了代码中查询文件信息的关联结构。
3、其他业务表名称字段。加这个字段是为了方便统计不同的业务，所占文件资源的大小。
总结：
通过这三个字段可以有效的管理文件表。如果文件表过大，可以清理一段时间之前数据状态字段为0的数据，同时释放服务器中保存的文件资源。

配置表

配置表除了key-value两个字段，创建时间字段（建议给个默认当前时间的默认值），更新时间字段，备注字段。除了这些，以下是我常用的其他字段：
1、业务编码字段。代表这个key-value为什么业务服务。有了这个字段在代码中，可以根据这个字段来查询key-value列表。
2、业务组字段。有时候一个大的业务可能包含好多的字段项。有时候针对一个大的业务更新部署，只要根据业务组查询出数量，就可以减少因为少配置项，带来的程序错误。

业务表中的数据状态什么时候加

我的经验是：业务主表加数据状态字段（1、有效；0无效）。但是具体情况还要具体分析：有一些很重要的附表建议还是不要真的删。
理由如下：
1、增加写sql的复杂度，一旦主表关联的附表太多，那你每个附表都需要判断数据状态（很麻烦）。而且一旦sql过长很少容易发生bug。
2、有一些不太重要的附表，存储这种假删除的数据，其实本身也是浪费数据库物理内存。
小建议：
主表的id,最好不要直接写命名id。一旦sql的关联的数据太多，多个id在一起很混乱啊！例如：订单id"order_id"哪怕你"dd_id"呢?也比直接id好啊！在我看来多敲几个字母这不是增加工作量的事！这要是一个长sql,你找对应id是不是还得找半天呢？死多少脑细胞啊！

主表的拆扩展表

说一说我拆表的经验啊：
1、表中有一个长文本很大的字段。比如：公告这类的业务。主体重要的就是一个长文本。但是在页面筛选时，不需要这个长文本，只需要主表的字段。这样在代码中处理逻辑就很简单。你用select * 的时候，不会影响查询速度。可能你说我不写select * 。但是你用不用mybatis+plus的selectById()吧。就算你也不用。你咋能保证你团队里的人不用。这种设计方式能让你的代码更简单，更高效。而且如公告这类的，还可以通过拆表保存长文本的编辑历史（配合数据状态字段），这种就是上述的说重要的附表要加数据状态字段。
2、主表中有相同业务的字段。比如：订单表中的支付信息。我们查询数据的时候，支付数据不是必须查的，可能只有在查询详情的时候才设计到。这样你代码的逻辑会很清晰，你用什么数据就关联什么数据附表。
3、表的数据会很大。百万、千万、亿级的数据表，后续运营时，如果数据太大，例如：在表中新增一列，可能需要停服务来处理新增列。这种情况建议把重要的列放到主表，不重要的列拆到扩展表，或者说必填的字段放到主表，不是必填的放到扩展表。一是方便后续维护，二是减少数据库null字段占用数据库资源。

表非null字段最好给默认值

像是创建时间，数据状态，修改时间这种辅助字段，很重要，我的建议是直接在数据库给默认值。省得不靠谱的程序员不给设置。
注意：
老的程序员可能会意识到创建时间、修改时间，这两个字段的重要。其实有时候排查生产的问题这两个字段会给你非常重要的辅助。至于具体怎么分析，还真的不太好举例。

日志表

日志表我的经验是有两种类型的日志表。
一、记录接口访问的，只需要记录接口的入参、返回值、调用路径、接口访问成功的状态，创建时间，如果是通用的加一个业务编码或者访问接口名称。
二、记录或描述一个业务流程的。字段如下：
1、流水号，一个业务流程唯一
2、业务主表主键，方便查询具体是哪个主表数据
3、业务编码，多个业务可以同时使用
4、当前阶段，一个业务流程进行到哪个阶段了，比如：下单业务，进行到创建订单阶段、支付阶段、退款阶段等
5、日志排序，在某一个业务阶段内，我打印了好几个重要的点，给这几个重要的点进行排序，简洁的恢复这个阶段内的数据流转
6、记录内容，在加日志处要记录的内容，比如：创建订单时的订单号、支付阶段时的金额或支付id，异常等等。想存啥存啥，方便你后续排查问题就行
7、是否成功标记，对一个阶段中的某一部操作是否成功！
8、创建时间，这不用说了。
9、数据状态，想啥呢，日志表要数据状态。这东西占用数据库资源太大的时候，都是可以删的，要啥数据状态。建议清除日志表的时候，不要直接删所有数据，根据创建日期，删
一周前、一月前，根据具体业务判断。

删除备份表（垃圾桶表）

这个是我闲着没事时，想出来的，生产上没有用过，算是一个想法把。仅供参考！！！
1、其他表id
2、其他表的名称
3、其他表的数据（JSON字符串）
4、创建时间
备注：
这个是当时灵光一现想到的，当我们在真的删除数据的时候，就不用管这个数据还用不用备份。直接在基础项目里写一个feign接口，把这些删除的数据都扔到这个垃圾桶表里面！就不用管了，万一想恢复，再把它根据表id找回来。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
以上说的各种表，都是不含表主键的，我都是挑重要的字段说的。突然想起来怕有些人直接抄啊！