百万级数据能这么干

    今天一上午就和供应商展开了激烈的火拼.
    我作为项目技术把关人，当然会鸡蛋里挑骨头。发现了系统的几个主要的缺陷，我觉得非常之不妥：
    1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
这不扯蛋吗？客户端要不程序死掉，要不内存溢出。服务器，广域网还不累个半死。
    2） 假设1）没有问题，下一步还得同时把数据写到类似银行的U盾（类似U盘）中去，如果写成功了，还得更新百万级数据的状态。U盘的速度能有多快呢？该过程会要持续很长。估计数据表都被锁定了。该表其它的用户就不能使用了。这真要命。应该分批分批的写入数据。
    3） U盘如果在系统运行过程中，如果松动或拔出，在重新插入，要把系统重启。这还不让人郁闷死？难道你把U盘拔出，还要重启操作系统？应该提供程序的健壮性。
    4） 6百个客户端直连数据库，保持长链接。这个一值保持怀疑的态度。我也写过测试，似乎没有问题，网上也说没有问题。但通常，较好的做法是在客户端和数据库中间有一个前置，由它统一处理。
    5） 客户端和服务端都通过数据库作为状态的同步。服务端根本不知道客户端处于什么状态，导致他们的数据不一致。通常都会用socket通讯，采用心跳机制。

    靠忽悠是不行的，还是要把系统设计好。价钱也不斐。

1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
不一定都要装内存啦。要不直接提供个excel 文件，自己下载。

4） 6百个客户端直连数据库，保持长链接。
和1差不多，可以先读到文件，然后让他们自己下载。

首先 1），2）要结合起来看。你可能没有理解到具体的需求。
 
一个Excel 工作表（Sheet）的最大行数为：65536。你想想要多少个sheet？，这个方案也不太好。

4） 6百个客户端直连数据库，保持长链接。
连接是指数据库的连接。要把客户端的数据实时的写入数据库。

我老婆公司是作这个的.
如果想换家试试这家
作过中信的项目.

ps:你的需求明明是上一个数据仓库
为何要实时?

谢谢抛哥，：）。由于该项目和Z F行为有关，而那家公司和Z F的关系非常好。该公司是Z F指定的，所以，，，
当然，我们已经给了明确的时间、任务，如果不能完成，我们将采用备用方案。备用方案，基本也是内定的。公司有些项目会招投标，有些也是走过场。 当然，我们会严格把关。感情是一回事，事情还是要做好。

每笔交易是实时的上传到数据库服务器。但在月末的时候要对账，就要从数据库中，把每笔交易从服务器上面，在主服务端上显示，然后写入到Ukey中。如果UKEY能写成功，同时要把状态更新回数据库。这个要事务处理。如果他们这个方案能行，写的时间也是一个非常大的问题。我正想写个例子，测试一下。

ukey根本是个笑话....
事务查出更新数据库更是扯
不如写日志.
一个批次.写二条日志.
日志一条开始写
另一条写结束
只要有开始有结束
就认为数据完整
有开始没结束或结束是error
就认为数据是不完整的.
银行还省这点小钱
拉根专线没几个钱.

不要试想着一次全部读出来写进去，可以试着分N批进行读写，这样耗的内存就不是很大了。

网银互连？

抓紧写程序，截测试，做评估。
语言没有说服力，能提出该方案的，脑子进水。
与其扯淡，不如面上先拖，底下干实事。

要成功拿下，必须有替代方案，让其认可。

等着看看楼主最好咋整的、