2，没 break 吧

使用一段时间 屏幕中下部会有亮斑，设计问题，在白色时很明显

文本文件就是二进制文件，如果文本规范的话，可以识别，主流的编码都有编码区间

本来只是吐个槽，没想到这么火，看来大家对存储过程怨念很大，我也没说太清楚

我这边做的系统是和联机系统分离的，主要做数据加工和报表，这边接手系统也两年了，原先我也是没用过存储过程的，接手后现学的，我觉得最大的优点就是直接操作数据减少 io 交互，效率高，所以一些不需要落地的加工我倾向用存储过程做，我们这边也没用到什么复杂的业务逻辑，真正复杂的也是用 java 实现的，另外考虑到去 ioe，后续数据库可能会变，我们其实已经在避免使用存储过程和一些与数据库版本有关联的 SQL 特性。

这个新领导之前在日企做 COBOL，来了先是说数据库没有文件读写效率高，让我们把数据都存成文件，他的理由就是同一份数据文件 cp 的时间比用 java select 再逐条 insert 到新表快很多，我说你用 ctas 呢，他又开始说存储过程难上手啥的，且不说 ctas 算不算存储过程的问题，就是觉得那边在纸上谈兵，完全脱离实际

@pagxir 我认可根据业务功能去做技术选型，之前也一直是这么做

但新来的领导要求所有问题都统一，比如不用存储过程就连 SQL 也都不用，不管应用场景，字段求和就是记录扫出来 java 里面加，update 就是符合条件扫出来，java 改字段再 update 进去，这种真的是好设计么？还是我思想过时了？

另外，移植性，灵活性是理由，我认可
难度，可维护性我不觉得有什么问题

@pagxir 其实我觉得不用存储过程我可以接受，我也说了可移植性不好，但领导那边连标准 SQL 都要求避免使用……

@cloudbeyond 问题是 SQL 都不用的话，还用数据库做什么…我们是做批量维护的功能，大部分应用场景就是根据某些条件去更新某字段，以及备份，加载这些，复制表用 java 一条一条的 select 再 insert 这种我真是从来没想到过

仔细想了一下，因为我这一组是公司组织调整，去年才整体划过来的，而去年我这组任务特别重，他原来的人也接不下来，现在大项目结束了，公司高层还有意要要他带我这组重构原来他那组做的系统，所以领导要对我这组下手了