技术是为业务服务的，业务离不开技术，技术离不开业务。很多人嘲笑 CRUD，C R U D：增删改查，CRUD不过是业务的基础部分，拥有再牛的技术但对C R U D 不熟练 如何架构及开发好整个系统？
C R U D 的思考
添加数据
添加数据如何设计？如何保持幂等性？如何保持接口的传输安全性？如何保持重放攻击？接口出错以后容错机制如何操作？对表单数据的检验，前后端如何校验？
一个表单中有多个业务融合在一起，是否为同一个接口？或者拆为多个接口？面对微服务架构情景的模式下又如何考虑？
面对复杂业务的表单，是否将该数据类型设置为json格式？拥有100多个字段的表单场景时如何设计？如何优化添加100多个字段，使用户的体验更好？
删除数据
在删除一条数据记录时，若一条数据贯穿整个系统的业务，如何优化？又如何保证对该数据相关的业务都删除？删除数据后，如何追踪导致其他菜单功能不可用？如何保持删除数据的粒度？
使用逻辑删除？还是物理删除？对删除的数据导致系统出现异常如何容错？
修改数据
修改表单数据时，和添加表单时的字段一样，是否要设置为同一个表单，根据标识判断添加修改？添加表单和修改是否分开更好，保持解耦合的原则？
修改时，查不到详情数据如何修改？如何优化修改需要填大量信息？优化修改表单为导入excel 避免单一操作？
查询数据
在业务查询时，如排序，使用数据库排序，还是程序排序？查询一个ID时关联多个业务，表设计为组合表，或者使用连接查询？
查询数据时，内部写了大量的业务，方法依赖上一个接口的数据时，上一个接口也要查库，如何追踪哪个接口查询速度慢，或异常导致功能异常？
以上在开发中还有各种各样的场景。一个c r u d 并不能说明什么，但是业务离不开C R U D，技术也不开。