其实两种方案在压力比较大或环境比较复杂的环境中都会有一定的问题或麻烦的地方。
就通过系统的数据对象直接连接数据来说吧，在面向Internet的网络来说，也有一定
的问题的，比如在 SQL 2000 的数据库，某条数据有 30 MB，然后7个用户同时访问
这条数据，不说 Internet 网络，就是局域网都有可能有一两个点挂掉。如果是数据
量小一点的记录，能承受多少个点同时访问同一条数据这很难做到比较全面的测试。
如果客户用 3G 或 GPRS 方式上网，那要处理比较大量的数据读写也是很困难的事。
总的来说，不出问题就好，如果出问题，这种第三方问题是很难自己解决的。
对于自己用Winsock写三层结构的服务程序与客户端来分发任务处理数据库的做法，
扩展性可以很强，可以满足很多自己的需求，但是相对的也会带来很多问题。
1、程序的稳定性
2、系统资源和程序性能的控制
3、数据传输的过程优化
但因为是自己做过程，出了什么问题，自己可以很方便跟中和解决问题，这点要比处理
第三方问题要好一点。
就程序的稳定性来说，要做到“稳定”，需要花很大的精力和时间，而 VB 本身自带的
WinSock 控件在 Internet 中表现本来就不是很稳定，不说 2000 个各地的 Internet
用户连接，就 200 个都可能会发现很多问题，如果自己用 API 写过程，在资源控制上
也会有一堆的问题。但这些不是不能解决的问题，只是需要时间和经验。
从系统资源和程序性能控制来看，VB这一块比较若，相对来说，VB 要做这种服务程序不是
很适合，如果换开发工具，当然可以解决这个问题，但开发难度也会随之增加。
从数据传输的过程优化来看，如果这点不做，对于一些网络环境不好或需要传输稍微大点数据
的开发需求来说，肯定会是个疙瘩，但要解决这个问题又需要了解并掌握一些比较高效的压缩
解压技术。比如使用 PPMD、LZMA 等技术做内存压缩，然后通过握手传输压缩数据，这样可以
提高网络传输数据的效率，不过这种过程要用 VB 来写效果不会太理想。
如果要用这种方案，还不如直接用一些 WEB 服务程序，用服务器脚本来实现传输和数据读写
过程。因为网络服务程序的稳定性就不用考虑的，直接交给IIS或阿帕奇等程序去处理，只要
直接写个 COM 组件或接口给脚本调用数据处理过程，客户端无论是使用现成的 HTTP 对象或
自己用写 Sock 客户端，都比较容易处理，稳定性和性能也有一定的保障，开发难度相对要
低很多。
