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

lwwvb

今天看到一个快速开发ACCESS的平台，说里面自动生成的窗体是非绑定表的。原因是使用绑定表，并发用户数多了，数据量大了会慢。

但是，造成这个慢的原因，道理也许是：
原因一：可能后台使用ACCESS 数据库。
原因二：DAO方式，而且使用ODBC接口，造成性能不佳。
原因三：设计不合理。

但如果我们使用ADP，多用户时，后台选用SQL SERVER,ADP一定是使用ADO的，再加上合理的设计。

在多用户并发，多数据时，会不会慢呢？比ODBC+MDB的方式好多少？
只因没有做过这样的多用户的工程，不能了解其中。
有经验的朋友可以讨论一下，用ADP时，你们使用绑定表，还是非绑定表？如果用户并发不是非常多的情况下，是否绑定表还是首选？

补充一下：后台同样是SQL 2008中，使用SQL SERVER PRO PROFILER监视，设计一个简单的主从表窗体。使用MDB+ODBC 方式中，打开主从窗体，看到SQL 2008要花下面SQL指令。
exec sp_unprepare 3
go
exec sp_unprepare 4
go
SELECT "dbo"."学生"."学号" FROM "dbo"."学生"
go
declare @p1 int
set @p1=5
exec sp_prepexec @p1 output,N'@P1 nvarchar(50)',N'SELECT "学号","姓名","年龄"  FROM "dbo"."学生"  WHERE "学号" = @P1',N'C2'
select @p1
go
exec sp_execute 5,N'C2'
go
select 504,c.name,c.description,c.definition from master.dbo.syscharsets c where c.id = convert(tinyint, databasepropertyex ( db_name() , 'sqlcharset'))
go
exec sp_executesql N'SELECT "窗体2"."ID" FROM "dbo"."成绩" "窗体2" WHERE ( @P1 = "学号" ) ',N'@P1 varchar(510)','C2'
go
exec sp_execute 5,N'C2'
go
declare @p1 int
set @p1=6
exec sp_prepexec @p1 output,N'@P1 nvarchar(50),@P2 nvarchar(50),@P3 nvarchar(50),@P4 nvarchar(50),@P5 nvarchar(50),@P6 nvarchar(50),@P7 nvarchar(50),@P8 nvarchar(50),@P9 nvarchar(50),@P10 nvarchar(50)',N'SELECT "学号","姓名","年龄"  FROM "dbo"."学生"  WHERE "学号" = @P1 OR "学号" = @P2 OR "学号" = @P3 OR "学号" = @P4 OR "学号" = @P5 OR "学号" = @P6 OR "学号" = @P7 OR "学号" = @P8 OR "学号" = @P9 OR "学号" = @P10',N'C1',N'C3',N'C3',N'C3',N'C3',N'C3',N'C3',N'C3',N'C3',N'C3'
select @p1
go


同一个条件，使用ADP,打开主从窗体要花下面SQL指令。


SET ROWCOUNT 10000
go
SELECT * FROM "dbo"."学生"
go
SET ROWCOUNT 0
go
SET FMTONLY ON select "学号" from  "dbo"."成绩" WHERE 1=2  SET FMTONLY OFFdeclare @p1 int
set @p1=1
exec sp_prepare @p1 output,N'@P1 nvarchar(50)',N'SELECT  *  FROM "dbo"."成绩" WHERE ((@P1 = "学号"))',1
select @p1
goSET ROWCOUNT 10000
goexec sp_executesql N'SELECT  *  FROM "dbo"."成绩" WHERE ((@P1 = "学号"))',N'@P1 nvarchar(2)',N'C2'
go
SET ROWCOUNT 0
go
EXEC sp_MShelpcolumns N'成绩', NULL, N'id', 1
go


看来，ODBC和ADP效率差很远。。。

风中漫步

路过,学习.感谢分享研究成果

laimf

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

laimf

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

lshstruc

我不是adp高手，这个论坛里的朱以文老师是，我是个爱好者，也谈一点看法：
1.楼主提到的，某开发平台提到的ODBC链接表方式实现C/S，如果采用绑定表会慢的说法，我也注意到了，而且这个说法很早就提出来了
2.我对adp与ODBC的性能与优越性比较问题学习了很长时间，各专业论坛上对于这个方面的讨论也是吵翻了天，各有各的意见，各领军派人物都有自己的看法。
3.论坛里力挺ADP的有朱老师，事实上截止到acc2003为止，microsoft也是力挺adp的。我记得有本英文acc开发宝典里面大概是这样说”odbc链接表是工作组内部实现C/S的一种可接受的解决方案，但ODBC链接表本质上仍然是以客户端为中心的，要建立以服务器为中心的C/S程序，应对多用户并发和海量数据，应该选择升迁。
4.但是实际应用中，很多人认为ODBC是优于ADP的，这中间不乏高手，而且你仔细观察会发现，现在做的比较成熟，模式比较固定的商业版本，基本上都是”ODBC链接表为基础+ado“的模式开发的，比如UMV开发平台，本站的王站的高大上的BEAT版，歌逸的平台（根据介绍未使用过不肯定）。当然，这里面有商业化，批量化，模式化需要的原因在里面，不仅仅是优越性，速度的问题决定的。
5.开发者的灵活和才智，odbc+ado模式,把access用到了极致，基本上都是窗体绑定表或查询并带上条件避免全表取数，只用来展示数据，不用来录入，录入又采用非绑定表，ado读写，避开ODBC直接与SQLSERVER取要用的少量记录。这种模式既充分利用了acc直接绑定表窗体代码少的优越性，又充分避开了绑定表录入要打开表加载表的弱点。
6.在acc的开发宝典里面，把传递查询作为odbc链接表方式访问SQLSERER推荐的方式，但实际上，极少有人在用这个东西，有人宁肯多写代码用ado取记录集然后绑定到窗体也不愿意用这个，而且网上对于这种技术的资料极少。
7.我试过传递查询技术，包括传递查询的写法，参数的传递方式，VBA创建传递查询等，其实非常好用，也比链接表效率高，但传递查询不能绑定到窗体作为录入窗体，我曾经有个想法，就是全篇使用传递查询来做开发，希望以后试试。
7.实际上我认为，acc最大与其他软件最大的区别就是1.绑定表，2.主子窗体，这也是acc最核心的优越性，没有了这两样，你还会用acc吗？
8.我看到的还有一些其他的开发模式，纯ado模式，适合于少数人，对性能，灵活性高度重视，对代码不屑一顾的人使用。
9.关于绑定表速度慢的问题，我认为不仅仅是odbc链接表的问题，放在adp里面是一样的，也会慢，这个应该主要是数据量造成的，楼主看到文章后，我昨天上午也看到了，我马做了一个测试，adp环境，窗体绑定一个170W条记录的表，直接打开窗体然后直接gotonewrecord,花了10S时间，环境WIN7+ACC2007+SQL2000，SQL是本地服务器，从硬盘存取数据，想想如果放在局域网里，得要多长时间打开？
10.在ADP中，C/S架构基于OLEDB，当通过窗体访问数据时，OLE DB 会从 SQL Server 数据库检索一个可更新快照的记录集，并在客户机上缓存这些数据，当处理窗体或数据表中的数据时，不论是浏览、筛选、排序、查找数据，还是更新数据，都是在处理缓存在客户机上的数据。
11.其实在acc中，绑定表方式访问数据库是微软推荐的方式，也是ACC的特点，对于绑定表会带来大量数据传输的问题，microsoft肯定能考虑到的，adp的窗体属性里面有一个dateentry属性，也有一个SERVERFILTER属性，新增记录时，把DATEENTRY属性设为true，窗体不加载任何数据直接打开，编辑记录时，利用SERVERFILTER属性，只取你要的记录，不加载全部数据，一点都不卡。与非绑定方式录入没有任何分别。我用176W条记录做了实验，新增和编辑都是秒开。
12.在mdb中，没有serverfilter属性，但是可以在打开窗体时设置DATEMODE为acformadd，和限制where条件，也是microsoft设计来应对绑定表加载数据问题的，我没有做实验，不知使用后效果与非绑定窗体如何。
13.acc为前台，后台还是ACC的模式下，局域网联网使用，除了数据量的问题，还存在一个记录锁定的问题，更加造成慢和卡的问题。
14.我觉得，我观察很多学acc的人，都过于偏重用vba代码，用dao，用ado解决问题，而对microsoft为我们提供的大量的acc自身自带的功能，属性，工具，控制办法，弃之一边。造成这种的原因我觉得主要有两个方面，第一是对acc自身特性不重视，对强大的MICORSOFT不够崇拜，第二是思维习惯不喜欢从方法上去解决问题，而习惯于从技术上与解决问题。
15.我现在做程序，都是自己企业用，我一直用的adp，我坚持一个原则是，能用acc自身功能实现的，坚决不写代码，能用自带控件解决的，坚决不引用第三方的，能利用窗体解决的，坚决不用ado，不在同一个界面上，实现过多的功能。尽可能做原生态的程序，主要做的好处是，1.稳定，2，bug少，3，好维护，4.软件分发后，没有什么乱七八糟的丢失的引用之类的。5.以上说的是我个人做程序，像专业的软件开发平台之类的，考虑到统一性，通用性，甚至自动生成，考虑的角度肯定和我是不一样的。
16.对于很多实际问题，其实以上谈到的几个开发平台都是专业的搞商业软件的，有的甚至搞了超过10年了，积累了大量的实际使用经验，对ACC的理解深度肯定和我不一样的，他们不建议绑定表肯定是有成熟经验的。
17.乱七八糟说了一段，非常不专业，纯粹给本站涨涨人气，凑凑热闹。

lwwvb

先为楼上发言鼓掌。感谢为我提供了一些思路。我也说一下升级ADP的理由,MDB的后台最终只适合单机单人用。局域网以上的应用，SQL SERVER才是王道。但SQL SERVER可以使用MDB+ODBC或ADP开发。为什么很多高手和商业软件坚持使用MDB+ODBC？我认为两点：
1.这是因为用ADP的话，要重新学习，代码要改写，造成负担，一些思维方式与MDB不同（因为数据与前台分离了）。为了避免麻烦，最好是不管它了。
2.MS在2013版后把ADP取消了。ADP最多用到2010版本。

而关于用绑定表还是非绑定，经过楼上的分析，这个慢的问题，一是程序员设计上的问题，二是不会使用软件中某些选项造成的性能问题。

我也赞同能简单就简单。如果不是到万不得已，最好还是使用绑定方式，免得为自己添麻烦。在ADO.NET上，数据集和数据链接已经分离，使用绑定绝不会有性能问题。

而快速开发平台生成窗体使用非绑定表，也许可能ODBC当时没有现在的那么先进？或也许是为了考虑适应各种开发者的水平和用户数量，而设计的一个方案？


但为什么我还是会对绑定表的使用有所担心，这是因为用户并发数非常多的时候，对服务器会是一个负担，ADO.NET采用断开式也是原因之一。而我只是想弄清这个极限在哪？但现在看来，不需要担心，放心用绑定表就是。


补充一下：我还是会继续用ADP来做SQL SERVER 的开发，理由是ADP比MDB+ODBC的分层要好（强制不能把VBA混在查询中）。这和其它开发工具的二层开发很接近。
如果用MDB+ODBC，开发中很容易使用MDB的思维，把VBA和查询/数据集混在一起用。这样，未处理好的数据有机会都会提取到客户端，会造成性能问题。
现代的数据库开发，都是向三层和多层发展的。ADP虽然中止在2010版本上，但并不代表ADP不好。相反，ADP是我们更进一步的基石。

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能如此广泛使用也跟这些因素有很大关系吧。

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

lshstruc

补充楼上LAIMF的第三条：
非常赞同楼上的处理办法，ODBC链接表处理纯数据，根据我的了解，速度还是挺好的，对于一个表中比较大的字段，不建议放在同一个记录集中打开，楼上的通过ADO来根据记录的主键单独寻找该字段，是一个好办法。
其实ACC的绑定窗体自身是支持绑定字段以外的控件的，绑定窗体上的控件除了绑定到字段，还可以绑定到表达式，而这个表达式是支持与绑定字段的控件联动的。
而对于该绑定表达式控件的值，是根据绑定字段计算得来的，microsoft的强大就在于，啥都替你想到了，如果你的记录集中有1000条记录，他却不会把1000条记录对应的表达式全部计算出来，然后放在内存里，他是这么处理的：
1.单个窗体：仅根据窗体当前记录计算对应的控件值，跳到下一条记录，重新计算下一条的控件值，并清除上一条的控件值。
2.连续窗体和数据表窗体：仅计算当前屏幕上显示的记录对应的控件值，通过滚动条滚动到下一页，重新计算下一页的控件值，并清除上一页的控件值。（19寸的屏幕和20寸的屏幕计算的量也是不一样的，窗口最大化和缩放后计算的量也是不一样的，很有意思）。
所以完全不用担心卡的问题，我没有处理过图片的问题，但是我处理过一个“备注”字段，用的也是这种方法：
1.窗体绑定到记录集，记录集不包含备注字段。
2.建一个非绑定的控件，直接用ACC自带的域聚合函数，控件值=DLOOKUP()，根据窗体绑定的记录ID查阅备注字段。
以上方法没有一句代码，没试过图片，不知能行不。
缺点是DLOOKUP 可能比自己写的ADO代码稍微慢，但完全用acc自身功能，基本不写代码，简单，稳定，可靠。而且支持数据表窗体和连续窗体，自动联动，特别适合我这样的懒人。

zpy2

用dbsqlpassthrouth调用存储过程

风中漫步

高手如云啊.