“天天做增删改查，一点进步都没有。”
“增删改查，太简单了！”
“全都是增删改查，一点技术含量都没有。”
以上，是我听到的好多编程人员说过的话。CRUD，增(Create)、读取查询(Retrieve)、更新(改，Update)、删除(Delete)。都说CRUD简单，CRUD真的简单吗？你可能会说是，但“初出茅庐”的我并不这样觉得。
本人做项目经验不长，写程序过程中总结的一些问题，特此记录下来：
查询
1.列表数据显示，是否判断了null及undefined的情况？
""空字符串还好，如果数据返回到前端有属性为"",页面显示直接是空的，不过为了好看一些，有的必要加上-替代下空，也是可以的。
null和undefined空值和未定义的值，数据返回到前端为null或undefined，这类数据就得判断一下了（当然，像vue等一些前端框架本身就处理了这些问题，如果前端数据为null或undefined，页面显示直接是空），如果不判断，用户看到实际为null或undefined这样的数据，肯定一头雾水了。
2.查询时，是否用ORDER BY将数据升序或降序排序了？
列表数据显示时，很多情况下是有必要将数据进行排序的。像有日期类型的字段，考虑有些是否需要用ORDER BY DESC降序排列下，像主键若是自增的，是否按主键ORDER BY了等等。如果不排序，数据显示的就会特别乱，比如用户刚添加了一条数据，本应该在列表中显示在第一行，一眼可看到的，但是找了好几页都没有找到，这就有问题了，这就是由于查询时没有对数据进行排序造成的。更可怕的是如果分页功能有问题，数据已经有很多页，而我添加的数据并没有在第一页显示，点分页又没作用，这可如何是好=.=(本人之前遇到过这种问题，所以吃一堑，长一智)。
3.像带有状态条件的数据，查询时是否根据相应条件正确过滤了数据？
如一个表中用status字段标识数据的可用性，0-正常；1-冻结；2-已删除，那么查询的时候status=2甚至status=1的数据就不能查询出来显示到页面中，你在查询的时候是否用WHERE STATUS=0来将数据过滤了？（这只是举了个栗子，当然还是按需求来）
删除
删除，分为软删除 和 硬删除。
所谓软删除就是删除时保留数据库表中相应记录，只是用UPDATE语句更新表中某个状态字段，标识为已删除(eg:第一部分第3条中提到的栗子)，而列表显示的时候是需要过滤掉这个字段中已删除的状态的。
硬删除，也就是永久删除。使用DELETE语句，彻底将相应记录从数据库表中删除。
做删除功能的时候，考虑到业务逻辑相关，其他表的相关字段是否需要清空？其他表的相关记录是否也需要一起删除或更新？这些都是要考虑到的。业务逻辑简单还好，要是复杂了，考虑的必定也就多了。
添加or修改
对于数据的添加，如果表中字段没有设置初始默认值，需要注意添加的时候需要添加上；修改时同理，哪些字段该修改，哪些字段是不必要或不可修改的，这需要好好熟悉理解业务。
……
[其他的遇到坑了再补充吧~ ]
总结
如果开发时期不注意相关细节，那么测试的时候就会面临代码的重复甚至大量修改，会非常麻烦。不管在查询、添加、修改还是删除，都需要根据业务、表中相应状态字段等等，去进行验证、匹配，确保数据的正确性、一致性。业务越复杂，表之间的关联关系也就越复杂，所以要很熟悉数据库表与表之间的关联关系，熟悉业务，这样做起来会很容易些。其实每写一个SQL，每做一次增删改查，都要从整个业务的关联关系角度思考下，这个事务是否会对其他业务有影响，有什么影响，怎么做是正确的。实践越多，犯错误无可避免，也会越多，自然总结的就会更多。要常常自我反省。正所谓吾日三省吾身，会省才会有进步。