搭建后台系统的一些总结教训

来的新公司接手一个新的项目，自己从0开始搭建了后台系统，由于之前都是用的老项目，底层都是前辈们搭建好的，自己在新系统中将老项目的思路借鉴了过来，以为可以高枕无忧，事实证明确实不行。项目在整个使用过程中，还是暴露出来了很多问题，这些问题在最初搭建项目时都没有很好的考虑到，导致后期要更改的话代价太大成本太高。所以自己将自己在搭建系统的工程中踩的坑吃的亏都记录下来。给后续自己搭建系统时做个参考。

1：系统将数据返给前端时，没有对 日期 类型做统一的格式化处理
系统返给前端的数据中少不了包含时间格式的数据，而前端也免不了要对时间格式的数据显示在界面。这时候，需要对时间格式在系统中做全局的统一格式化处理，设置成用户友好型的格式内容。

2：系统返回数据给前端时，对变量命名没有做统一规定
系统中，数据库设计中字段名是下划线命名方式，而在实体类中是驼峰命名方式。这就导致了，将整个对象返给前端时，前端拿到的是驼峰命名的变量，如果是用sql直接查出来数据返给前端时，前端拿到的是下划线形式的变量。 这导致前端相似模块不能复用同一个组件。成本极大提高。

3：前端拿到的列表页数据每条包含多个id
在list接口中展示列表页信息时，后台可能对应多表联查的情况，在多表联查时，不能写select * 这样的sql , 要保证每条记录前端只能拿到一个id。

4：设计数据库时，有主外键关系的字段，数据类型一定要统一
这在我设计数据库时体会颇深。不同表之间有字段映射关系时，字段类型一定要统一，字段名尽量要一致。选择字段时，也要充分考虑数据库字段对应到java的数据类型。 如果数据库字段选择的是INT , 而相关表映射字段确选择了NUMBER, 这将给自己的编码带来很大的麻烦。 比如INT在java中要对应Integer ， 而NUMBER在java中要对应double ，这么在写相关查询时，每次都需要将double转为Integer或者将Integer转为double。

5：设计数据库时，如果id 和 某字段都能唯一标识一条记录， 做主外键关联映射到其他表时，选择没有业务含义的字段（id）映射到其他表
在 工程表中， id和施工许可证编号都能唯一确定某个工程， 将工程表关联到 摄像头表，车辆表等相关表时，推荐将id作为关联字段，使用施工许可证编码做关联绝对是我设计系统时一个重大的失误！因为一旦用施工许可证编号关联了其他表，因为施工许可证编号是工程的业务属性字段，后期工程要修改施工许可证编号， 与他相关联的表的施工许可证编号都需要修改！牵一发而动全身，很麻烦！

6：系统缓存中存放通用数据，提供获取该数据的接口前，一定要做深拷贝。不能让调用方的接口直接操作缓存数据，尤其是这些数据是通用公用数据的情况下。
我在设计系统时，设计了系统通用编码数据，这些数据一旦启动就会放在缓存中，并且对外提供获取缓存数据的方法。但是在返回系统数据前，没有对数据做深拷贝，导致直接将系统中的数据返回给调用方，调用方可以直接操作缓存中的通用数据！这时如果一旦调用方删除了缓存中的某个数据，其他调用方刚好用到了这个数据，那么就会出问题！ 所以在返回给调用方系统缓存数据前，一定要将缓存数据拷贝一份一模一样的返回给调用方。不能让调用方直接操作缓存数据。