用ADP的高手们，是绑定表还是使用SQL语句处理窗体？

laimf

实际使用中，具体的查询语句在客户端执行，还是服务器上执行，以及查询语句本身的执行效率，对性能的影响更多。多用户问题，更多需要考虑并行处理时的效率问题。我现在用MDB链接表客户端加SQL服务器，以及MDB客户端本地表，结合ADO，DAO等处理数据。50人同时使用，一点也不感觉慢。

laimf

复杂应用，可以考虑将服务器数据导入客户端本地表，处理完后再上传到数据库服务器。
只要遵循客户端与服务器端交换数据尽量“量小和时间短”。就不会错。有些数据是在服务器上处理，还是在客户端处理。这个不好说，没有固定的模式，要具体情况具体分析。

laimf

以上老师的讲解，让我体会到ADP + SQL 方式与 MDB +SQL的方式，是两个侧重点不同的两条路，绑定与不绑定肯定是效率有些差别。一个严谨规范专业，一个简单灵活多样。看各人的喜好，或者具体的实际应用情况来定吧。

1。 ADP + SQL 效率的确更高些，可以看作是直接链接吧。更倾向于把数据分派给SQL服务器去处理。也就是说方便我们大量使用存储过程去处理更多更复杂计算的数据。很多的功能修改维护，直接修改SQL语句就行了，客户端都不用去升级。对数据的处理客户端可以做到很简洁。当然缺点就是服务器会承受更大的负载，需要服务器要足够强大。

2。 MDB +SQL 更灵活些，通过ODBC可以方便链接更多的数据源，系统的负载可以更简单的分摊到服务器或者客户端。处理数据可以是SQL服务器，参数查询可以用传递查询（我也没用过），也可以在客户端链接表（或者本地表）处理数据（但是链接表处理比较复杂的SQL语句效率很明显没有在SQL服务器上效率高，这个我优化过一些数据库系统能非常显著的体会得到。）。 MDB +SQL还有个优势，可以使用本地表很好分摊服务器负载。MDB +SQL  由于灵活，多样性，给人感觉是比较松散，后期维护，或者另一个人来维护，遇到略微复杂的系统，就会抓狂找不到北的。

3。 我说说我体会到的绑定与非绑定吧，绑定的简洁性就不说了。其实更重要的是数据源是个什么样的数据源这个因素对性能影响更大，是绑定一条记录，还是绑定一个记录集，这个不同需求是不一样的。非绑定窗体的数据源如果是个很大的有很复杂计算的数据集，同样也是可以慢到系统崩溃。我个人感觉ACCESS2010的链接表的性能比以前任何版本的ACCESS的链接表性能都好。lshstruc 老师说了那么多的条例清晰的总结，研究的很深刻，把实践中的很多有效的方法都表达出来了，让我受益匪浅。
      拆分数据源，绑定与非绑定的ADO连接结合的处理方式，哈哈，能偷懒我一定偷懒，我这里有一张带图片的的大小30多GB的一张链接表，（很明显，链接表已经是经过ACCESS优化过了，因为打开一张表的速度比在SQL中打开这张表快很多。）客户端是父子窗体的数据呈现方式，按照常规方法，链接表效果不好，比较慢，但能打开窗体。用ADO连接整体一张表数据集是根本不行 ，比链接表绑定性能更差，直接死机。系统都会直接搞崩溃，系统服务器和客户端都会负载很大。我把数据集拆分成两个部分，一个是剔除图片字段的记录集，一个是图片的单条记录。我用链接表数据源剔除图片字段作为数据集直接绑定到窗体，图片用ADO只加载需要在窗体显示的那张图片，问题就解决了。当然用ADO连接两个数据源加载到窗体也行，代码多一点。我是懒人，不愿意两个ADO连接了。我这个例子说明有时候绑定与非绑定，都不是问题的根本所在。

4。 大数据的处理不管绑定或非绑定，哪种方式效果都不会好。更多的问题反映在系统的架构，服务器的磁盘、磁盘的接口和网络等是性能瓶颈了。我们现在的产品BOM应用，在大型商业软件的性能远没有我们自己开发的系统性能好，说明一个复杂系统的性能，最关键还是系统的架构要科学合理。硬件可以通过升级去提高，系统架构一旦定下来了，再去修改，跟重新开发没多少区别。

5。 开发中，我们掌握了用户的使用情况，比如记录数，字段大小，计算的复杂程度，用户数，业务流程，服务器性能，客户机性能，网络等情况，更能开发出科学合理的系统出来。这也是为什么很多时候商用软件不如业务人员自己开发的系统好用的重要原因。ACCESS能如此广泛使用也跟这些因素有很大关系吧。

    吃中饭时间到了 。。。。。。。。