我正在开发一个SQL库项目,该项目将处理QuickBooks和stores之间的事务,使两个数据存储保持同步。这很好,但初始同步将是一个相当大的事务集。初始同步完成后,事务将在产品的剩余生命周期内根据需要进行同步。
在这一点上,我非常熟悉使用QBFC的SDK,以及通过Paul Keister的僵尸项目OSR提供的各种资源和示例代码(谢谢,Paul!)还有其他的。所有这些资源都帮了大忙。但我还没有遇到的一件事是,通过单个消息集请求处理大量数据是否存在限制,或者是否存在大量或致命的性能成本。据我所知,SQL端的数据库也只是一个QuickBooks数据库,但我不想做任何假设。
同样,我只需要完成一次,所以我不想设计一个单独的解决方案来进行导入。这也为我提供了一个根据我的库、日志和所有内容测试实时数据副本的机会。
无论如何,这是我在Stack上的第一篇帖子,如果我以任何方式偏离了方向,请随时在这里发帖来教育我。谢谢。
发布于 2013-08-31 02:46:08
无论如何,我发现在网络环境中(而不是所有事情都发生在一个盒子上),拥有一个更大的MsgSetRequest比一个更小的更好。当然,每件事都有它的极限,也许我只是从来没有达到它。我不记得请求集到底有多大,但它确实很大。性能提升很容易达到10 :1甚至更高。
如果我是你,我会从头开始在我的设计中构建某种类型的迭代(迭代您的SQL数据集)。从一个很大的数字开始,它可以一次完成所有的工作,如果打破了,只需要缩小它,直到你找到一些有效的东西。
我知道这个答案没有你想要的细节,但希望它能有所帮助。
https://stackoverflow.com/questions/18520556
复制相似问题