数据库中表设计的一点点小体会

最近练手性质的接手了一个小项目，做了这个项目的数据表设计，并且根据这些表进行开发，开发到中后期，明显感觉表的设计有很多不合理的地方，在此挑一些记录下来。

关于主键

可以唯一标识一条记录的字段，我们可以将其作为主键。在我们这个系统中，结合框架（hibernate）的一些特性，表中一般有六个基本字段：id（Long型），create_by，create_date，modify_date，last_modify_by,version（大概是这几个，可能单词有拼错的，但大致意思是这样的）。
我要说的是id这个字段。我在设计表的时候，例如合同表，合同编号contranct_no可以作为记录的唯一标识值，而用一个long型的id标识记录也可以，区别在于contract_no有实际含义，而id除了标识唯一值没有其他的作用，再加上合同编号也是一串数字，为了不冗余，我直接将contract_no的值存于id字段，而去掉了contract_no这个字段。
但在后续的开发过程中我逐渐意识到了问题。这种做法的弊端在于扩展性不行。
后续的需求中，如果出现了变更这一操作，将造成很大的麻烦。

id(即所谓的合同编号)	电话	是否启用
20220101001	13312345678	是
20220101002	13412345678	是
20220101003	17712345678	是

现在我需要更改第一条记录的电话，但是由于133这个号码在其他记录中有业务关联，我需要保留这个历史号码，那么问题就出现了。我无法在保留原合同编号的情况先做到这一点，我只能废掉一条合同，然后将旧合同的数据复制到新合同中。
根据这个业务场景我们大概可以感觉到，主键，最好就用一个无实际含义的id来充当，不要赋予他其他的现实意义。

id	contract_no	电话	是否启用
001	20220101001	13312345678	停用
002	20220101002	13412345678	是
003	20220101003	17712345678	是
004	20220101001	13387654321	是

当然，上述情况的出现有很大一部分原因也在于我们的需求调研的不够全面。

关于冗余

最开始设计的时候，用户表有id和name，id作为主键，在其他表中含有用户信息的时候，几乎都是只存了用户的id（虽然想到了name比较常用，但设计的时候犯懒，就没有在每一个表中都增加对应的name字段），因为想着根据id可以将name等信息查出来，这样可以减少冗余，其他的表也基本这样，比如项目只存项目id，银行只存银行id。但是后面编程的时候才觉得这样实在是太麻烦了。比如name这个值，基本有id的地方就必然会需要name，最最关键的是，通常只需要一个name去返回到前端，这就导致每次都需要join表，或者去另写sql查找，这样其实很影响效率。
所以，对于常用的字段，最好还是做一下冗余，这样在后期写代码和数据库查找的时候会帮很大的忙。

关于增删改查

困了。。。明天写