B/S模式大批量数据处理方式

   我们在开发企业B/S模式MIS系统时候，总是会遇到需要执行存储过程的要求。对于大批量数据的处理一般设计都会放到存储过程中操作。那就存在一个问题，如界面有一个按钮是执行一个存储过程，这个过程相当费时，一般都在3个小时以上。对于这种处理，现在都是开单独开一个线程，界面直接返回信息，后台让他自己运行，这样不影响前台业务经办。但是用户发现点击后去查询执行结果，发现无数据，又再次点击，这样就再次执行过程引起数据错误。
   我现在的操作方式是点击按钮后就使用一张表记录状态，过程执行完成后再修改状态使得前台按钮可用。
   不知道大家还有什么方法没有？[size=x-small][/size]

我也想知道如何解决。

使用状态机，给这批数据标识一个状态，然后就比较好处理了。

你这算是异步操作了。

但，如果批量执行中，发现有数据问题，而无法导入呢？你咋让用户知道呢？比如说，一些必须保证唯一性的数据，电话号码之类的....

我们的项目中，都没有像你这样做。就是很普通的，让用户界面等待服务端批量导入完成后，给用户结果信息。是比较烦，但没有好的方式

优化一下查询界面的返回结果,提示用户: 数据正在处理中,现在还不能查,等会儿再来

你这个大批量数据处理是否是统计?
统计最好是采用增量方式, 增加/修改/删除一条记录之后就更新统计量. 这样直接查询统计结果就ok.
如果不是增量,可以定时执行统计存储过程产生统计数据存起来.

在线程类里加一个boolean型的静态变量 isReady=false， 进入时判断isReady状态，处理前修改状态为false，处理完毕修改isReady状态;
如果处理完后
要有结果展示给前端，还需要把结果存到数据库里

不知道你的什么按钮操作有这么大的数据量，3个小时的DB处理时间，很恐怖了。这种只有在后台异步做了。
但是我总感觉如果client端的一个button的处理数据量如此之大是不是设计上就有缺陷呢？
不知道能否提供详细一点的信息，比如你的那个button是要完成什么功能之类的，然后后台做了什么，或许从设计上优化会好一点。

什么操作需要做三个小时？
完全可以从系统设计上面考虑如何把三个小时优化为30分钟

如果无法进行优化，可以考虑断点恢复机制，采用时间切片（或者其他的分离数据的方式）的水平方式对数据分批进行并发处理，并且保存每次分批的处理结果，即使中断了，也可以重新触发。


我们这里的500W的数据，入库 + 处理 + 归档 大概30分钟

这样长时间的处理不应该放在可以“点”的功能上，直接后台定时调用。

告诉用户XX数据要每周星期几X点以后才会有结果。

你现在这样处理也可以。