用ADP的高手們，是綁定表還是使用SQL語句處理窗體？

lwwvb

今天看到一個快速開發(fā)ACCESS的平臺，說里面自動生成的窗體是非綁定表的。原因是使用綁定表，并發(fā)用戶數(shù)多了，數(shù)據(jù)量大了會慢。

但是，造成這個慢的原因，道理也許是：
原因一：可能后臺使用ACCESS 數(shù)據(jù)庫。
原因二：DAO方式，而且使用ODBC接口，造成性能不佳。
原因三：設(shè)計不合理。

但如果我們使用ADP，多用戶時，后臺選用SQL SERVER,ADP一定是使用ADO的，再加上合理的設(shè)計。

在多用戶并發(fā)，多數(shù)據(jù)時，會不會慢呢？比ODBC+MDB的方式好多少？
只因沒有做過這樣的多用戶的工程，不能了解其中。
有經(jīng)驗的朋友可以討論一下，用ADP時，你們使用綁定表，還是非綁定表？如果用戶并發(fā)不是非常多的情況下，是否綁定表還是首選？

補充一下：后臺同樣是SQL 2008中，使用SQL SERVER PRO PROFILER監(jiān)視，設(shè)計一個簡單的主從表窗體。使用MDB+ODBC 方式中，打開主從窗體，看到SQL 2008要花下面SQL指令。
exec sp_unprepare 3
go
exec sp_unprepare 4
go
SELECT "dbo"."學(xué)生"."學(xué)號" FROM "dbo"."學(xué)生"
go
declare @p1 int
set @p1=5
exec sp_prepexec @p1 output,N'@P1 nvarchar(50)',N'SELECT "學(xué)號","姓名","年齡"  FROM "dbo"."學(xué)生"  WHERE "學(xué)號" = @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 = "學(xué)號" ) ',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 "學(xué)號","姓名","年齡"  FROM "dbo"."學(xué)生"  WHERE "學(xué)號" = @P1 OR "學(xué)號" = @P2 OR "學(xué)號" = @P3 OR "學(xué)號" = @P4 OR "學(xué)號" = @P5 OR "學(xué)號" = @P6 OR "學(xué)號" = @P7 OR "學(xué)號" = @P8 OR "學(xué)號" = @P9 OR "學(xué)號" = @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"."學(xué)生"
go
SET ROWCOUNT 0
go
SET FMTONLY ON select "學(xué)號" 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 = "學(xué)號"))',1
select @p1
goSET ROWCOUNT 10000
goexec sp_executesql N'SELECT  *  FROM "dbo"."成績" WHERE ((@P1 = "學(xué)號"))',N'@P1 nvarchar(2)',N'C2'
go
SET ROWCOUNT 0
go
EXEC sp_MShelpcolumns N'成績', NULL, N'id', 1
go


看來，ODBC和ADP效率差很遠(yuǎn)。。。

風(fēng)中漫步

路過,學(xué)習(xí).感謝分享研究成果

laimf

實際使用中，具體的查詢語句在客戶端執(zhí)行，還是服務(wù)器上執(zhí)行，以及查詢語句本身的執(zhí)行效率，對性能的影響更多。多用戶問題，更多需要考慮并行處理時的效率問題。我現(xiàn)在用MDB鏈接表客戶端加SQL服務(wù)器，以及MDB客戶端本地表，結(jié)合ADO，DAO等處理數(shù)據(jù)。50人同時使用，一點也不感覺慢。

laimf

復(fù)雜應(yīng)用，可以考慮將服務(wù)器數(shù)據(jù)導(dǎo)入客戶端本地表，處理完后再上傳到數(shù)據(jù)庫服務(wù)器。
只要遵循客戶端與服務(wù)器端交換數(shù)據(jù)盡量“量小和時間短”。就不會錯。有些數(shù)據(jù)是在服務(wù)器上處理，還是在客戶端處理。這個不好說，沒有固定的模式，要具體情況具體分析。

lshstruc

我不是adp高手，這個論壇里的朱以文老師是，我是個愛好者，也談一點看法：
1.樓主提到的，某開發(fā)平臺提到的ODBC鏈接表方式實現(xiàn)C/S，如果采用綁定表會慢的說法，我也注意到了，而且這個說法很早就提出來了
2.我對adp與ODBC的性能與優(yōu)越性比較問題學(xué)習(xí)了很長時間，各專業(yè)論壇上對于這個方面的討論也是吵翻了天，各有各的意見，各領(lǐng)軍派人物都有自己的看法。
3.論壇里力挺ADP的有朱老師，事實上截止到acc2003為止，microsoft也是力挺adp的。我記得有本英文acc開發(fā)寶典里面大概是這樣說”odbc鏈接表是工作組內(nèi)部實現(xiàn)C/S的一種可接受的解決方案，但ODBC鏈接表本質(zhì)上仍然是以客戶端為中心的，要建立以服務(wù)器為中心的C/S程序，應(yīng)對多用戶并發(fā)和海量數(shù)據(jù)，應(yīng)該選擇升遷。
4.但是實際應(yīng)用中，很多人認(rèn)為ODBC是優(yōu)于ADP的，這中間不乏高手，而且你仔細(xì)觀察會發(fā)現(xiàn)，現(xiàn)在做的比較成熟，模式比較固定的商業(yè)版本，基本上都是”O(jiān)DBC鏈接表為基礎(chǔ)+ado“的模式開發(fā)的，比如UMV開發(fā)平臺，本站的王站的高大上的BEAT版，歌逸的平臺（根據(jù)介紹未使用過不肯定）。當(dāng)然，這里面有商業(yè)化，批量化，模式化需要的原因在里面，不僅僅是優(yōu)越性，速度的問題決定的。
5.開發(fā)者的靈活和才智，odbc+ado模式,把access用到了極致，基本上都是窗體綁定表或查詢并帶上條件避免全表取數(shù)，只用來展示數(shù)據(jù)，不用來錄入，錄入又采用非綁定表，ado讀寫，避開ODBC直接與SQLSERVER取要用的少量記錄。這種模式既充分利用了acc直接綁定表窗體代碼少的優(yōu)越性，又充分避開了綁定表錄入要打開表加載表的弱點。
6.在acc的開發(fā)寶典里面，把傳遞查詢作為odbc鏈接表方式訪問SQLSERER推薦的方式，但實際上，極少有人在用這個東西，有人寧肯多寫代碼用ado取記錄集然后綁定到窗體也不愿意用這個，而且網(wǎng)上對于這種技術(shù)的資料極少。
7.我試過傳遞查詢技術(shù)，包括傳遞查詢的寫法，參數(shù)的傳遞方式，VBA創(chuàng)建傳遞查詢等，其實非常好用，也比鏈接表效率高，但傳遞查詢不能綁定到窗體作為錄入窗體，我曾經(jīng)有個想法，就是全篇使用傳遞查詢來做開發(fā)，希望以后試試。
7.實際上我認(rèn)為，acc最大與其他軟件最大的區(qū)別就是1.綁定表，2.主子窗體，這也是acc最核心的優(yōu)越性，沒有了這兩樣，你還會用acc嗎？
8.我看到的還有一些其他的開發(fā)模式，純ado模式，適合于少數(shù)人，對性能，靈活性高度重視，對代碼不屑一顧的人使用。
9.關(guān)于綁定表速度慢的問題，我認(rèn)為不僅僅是odbc鏈接表的問題，放在adp里面是一樣的，也會慢，這個應(yīng)該主要是數(shù)據(jù)量造成的，樓主看到文章后，我昨天上午也看到了，我馬做了一個測試，adp環(huán)境，窗體綁定一個170W條記錄的表，直接打開窗體然后直接gotonewrecord,花了10S時間，環(huán)境WIN7+ACC2007+SQL2000，SQL是本地服務(wù)器，從硬盤存取數(shù)據(jù)，想想如果放在局域網(wǎng)里，得要多長時間打開？
10.在ADP中，C/S架構(gòu)基于OLEDB，當(dāng)通過窗體訪問數(shù)據(jù)時，OLE DB 會從 SQL Server 數(shù)據(jù)庫檢索一個可更新快照的記錄集，并在客戶機上緩存這些數(shù)據(jù)，當(dāng)處理窗體或數(shù)據(jù)表中的數(shù)據(jù)時，不論是瀏覽、篩選、排序、查找數(shù)據(jù)，還是更新數(shù)據(jù)，都是在處理緩存在客戶機上的數(shù)據(jù)。
11.其實在acc中，綁定表方式訪問數(shù)據(jù)庫是微軟推薦的方式，也是ACC的特點，對于綁定表會帶來大量數(shù)據(jù)傳輸?shù)膯栴}，microsoft肯定能考慮到的，adp的窗體屬性里面有一個dateentry屬性，也有一個SERVERFILTER屬性，新增記錄時，把DATEENTRY屬性設(shè)為true，窗體不加載任何數(shù)據(jù)直接打開，編輯記錄時，利用SERVERFILTER屬性，只取你要的記錄，不加載全部數(shù)據(jù)，一點都不卡。與非綁定方式錄入沒有任何分別。我用176W條記錄做了實驗，新增和編輯都是秒開。
12.在mdb中，沒有serverfilter屬性，但是可以在打開窗體時設(shè)置DATEMODE為acformadd，和限制where條件，也是microsoft設(shè)計來應(yīng)對綁定表加載數(shù)據(jù)問題的，我沒有做實驗，不知使用后效果與非綁定窗體如何。
13.acc為前臺，后臺還是ACC的模式下，局域網(wǎng)聯(lián)網(wǎng)使用，除了數(shù)據(jù)量的問題，還存在一個記錄鎖定的問題，更加造成慢和卡的問題。
14.我覺得，我觀察很多學(xué)acc的人，都過于偏重用vba代碼，用dao，用ado解決問題，而對microsoft為我們提供的大量的acc自身自帶的功能，屬性，工具，控制辦法，棄之一邊。造成這種的原因我覺得主要有兩個方面，第一是對acc自身特性不重視，對強大的MICORSOFT不夠崇拜，第二是思維習(xí)慣不喜歡從方法上去解決問題，而習(xí)慣于從技術(shù)上與解決問題。
15.我現(xiàn)在做程序，都是自己企業(yè)用，我一直用的adp，我堅持一個原則是，能用acc自身功能實現(xiàn)的，堅決不寫代碼，能用自帶控件解決的，堅決不引用第三方的，能利用窗體解決的，堅決不用ado，不在同一個界面上，實現(xiàn)過多的功能。盡可能做原生態(tài)的程序，主要做的好處是，1.穩(wěn)定，2，bug少，3，好維護，4.軟件分發(fā)后，沒有什么亂七八糟的丟失的引用之類的。5.以上說的是我個人做程序，像專業(yè)的軟件開發(fā)平臺之類的，考慮到統(tǒng)一性，通用性，甚至自動生成，考慮的角度肯定和我是不一樣的。
16.對于很多實際問題，其實以上談到的幾個開發(fā)平臺都是專業(yè)的搞商業(yè)軟件的，有的甚至搞了超過10年了，積累了大量的實際使用經(jīng)驗，對ACC的理解深度肯定和我不一樣的，他們不建議綁定表肯定是有成熟經(jīng)驗的。
17.亂七八糟說了一段，非常不專業(yè)，純粹給本站漲漲人氣，湊湊熱鬧。

lwwvb

先為樓上發(fā)言鼓掌。感謝為我提供了一些思路。我也說一下升級ADP的理由,MDB的后臺最終只適合單機單人用。局域網(wǎng)以上的應(yīng)用，SQL SERVER才是王道。但SQL SERVER可以使用MDB+ODBC或ADP開發(fā)。為什么很多高手和商業(yè)軟件堅持使用MDB+ODBC？我認(rèn)為兩點：
1.這是因為用ADP的話，要重新學(xué)習(xí)，代碼要改寫，造成負(fù)擔(dān)，一些思維方式與MDB不同（因為數(shù)據(jù)與前臺分離了）。為了避免麻煩，最好是不管它了。
2.MS在2013版后把ADP取消了。ADP最多用到2010版本。

而關(guān)于用綁定表還是非綁定，經(jīng)過樓上的分析，這個慢的問題，一是程序員設(shè)計上的問題，二是不會使用軟件中某些選項造成的性能問題。

我也贊同能簡單就簡單。如果不是到萬不得已，最好還是使用綁定方式，免得為自己添麻煩。在ADO.NET上，數(shù)據(jù)集和數(shù)據(jù)鏈接已經(jīng)分離，使用綁定絕不會有性能問題。

而快速開發(fā)平臺生成窗體使用非綁定表，也許可能ODBC當(dāng)時沒有現(xiàn)在的那么先進(jìn)？或也許是為了考慮適應(yīng)各種開發(fā)者的水平和用戶數(shù)量，而設(shè)計的一個方案？


但為什么我還是會對綁定表的使用有所擔(dān)心，這是因為用戶并發(fā)數(shù)非常多的時候，對服務(wù)器會是一個負(fù)擔(dān)，ADO.NET采用斷開式也是原因之一。而我只是想弄清這個極限在哪？但現(xiàn)在看來，不需要擔(dān)心，放心用綁定表就是。


補充一下：我還是會繼續(xù)用ADP來做SQL SERVER 的開發(fā)，理由是ADP比MDB+ODBC的分層要好（強制不能把VBA混在查詢中）。這和其它開發(fā)工具的二層開發(fā)很接近。
如果用MDB+ODBC，開發(fā)中很容易使用MDB的思維，把VBA和查詢/數(shù)據(jù)集混在一起用。這樣，未處理好的數(shù)據(jù)有機會都會提取到客戶端，會造成性能問題。
現(xiàn)代的數(shù)據(jù)庫開發(fā)，都是向三層和多層發(fā)展的。ADP雖然中止在2010版本上，但并不代表ADP不好。相反，ADP是我們更進(jìn)一步的基石。

laimf

以上老師的講解，讓我體會到ADP + SQL 方式與 MDB +SQL的方式，是兩個側(cè)重點不同的兩條路，綁定與不綁定肯定是效率有些差別。一個嚴(yán)謹(jǐn)規(guī)范專業(yè)，一個簡單靈活多樣�？锤魅说南埠�，或者具體的實際應(yīng)用情況來定吧。

1。 ADP + SQL 效率的確更高些，可以看作是直接鏈接吧。更傾向于把數(shù)據(jù)分派給SQL服務(wù)器去處理。也就是說方便我們大量使用存儲過程去處理更多更復(fù)雜計算的數(shù)據(jù)。很多的功能修改維護，直接修改SQL語句就行了，客戶端都不用去升級。對數(shù)據(jù)的處理客戶端可以做到很簡潔。當(dāng)然缺點就是服務(wù)器會承受更大的負(fù)載，需要服務(wù)器要足夠強大。

2。 MDB +SQL 更靈活些，通過ODBC可以方便鏈接更多的數(shù)據(jù)源，系統(tǒng)的負(fù)載可以更簡單的分?jǐn)偟椒��?wù)器或者客戶端。處理數(shù)據(jù)可以是SQL服務(wù)器，參數(shù)查詢可以用傳遞查詢（我也沒用過），也可以在客戶端鏈接表（或者本地表）處理數(shù)據(jù)（但是鏈接表處理比較復(fù)雜的SQL語句效率很明顯沒有在SQL服務(wù)器上效率高，這個我優(yōu)化過一些數(shù)據(jù)庫系統(tǒng)能非常顯著的體會得到。）。 MDB +SQL還有個優(yōu)勢，可以使用本地表很好分?jǐn)偡��?wù)器負(fù)載。MDB +SQL  由于靈活，多樣性，給人感覺是比較松散，后期維護，或者另一個人來維護，遇到略微復(fù)雜的系統(tǒng)，就會抓狂找不到北的。

3。 我說說我體會到的綁定與非綁定吧，綁定的簡潔性就不說了。其實更重要的是數(shù)據(jù)源是個什么樣的數(shù)據(jù)源這個因素對性能影響更大，是綁定一條記錄，還是綁定一個記錄集，這個不同需求是不一樣的。非綁定窗體的數(shù)據(jù)源如果是個很大的有很復(fù)雜計算的數(shù)據(jù)集，同樣也是可以慢到系統(tǒng)崩潰。我個人感覺ACCESS2010的鏈接表的性能比以前任何版本的ACCESS的鏈接表性能都好。lshstruc 老師說了那么多的條例清晰的總結(jié)，研究的很深刻，把實踐中的很多有效的方法都表達(dá)出來了，讓我受益匪淺。
      拆分?jǐn)?shù)據(jù)源，綁定與非綁定的ADO連接結(jié)合的處理方式，哈哈，能偷懶我一定偷懶，我這里有一張帶圖片的的大小30多GB的一張鏈接表，（很明顯，鏈接表已經(jīng)是經(jīng)過ACCESS優(yōu)化過了，因為打開一張表的速度比在SQL中打開這張表快很多。）客戶端是父子窗體的數(shù)據(jù)呈現(xiàn)方式，按照常規(guī)方法，鏈接表效果不好，比較慢，但能打開窗體。用ADO連接整體一張表數(shù)據(jù)集是根本不行 ，比鏈接表綁定性能更差，直接死機。系統(tǒng)都會直接搞崩潰，系統(tǒng)服務(wù)器和客戶端都會負(fù)載很大。我把數(shù)據(jù)集拆分成兩個部分，一個是剔除圖片字段的記錄集，一個是圖片的單條記錄。我用鏈接表數(shù)據(jù)源剔除圖片字段作為數(shù)據(jù)集直接綁定到窗體，圖片用ADO只加載需要在窗體顯示的那張圖片，問題就解決了。當(dāng)然用ADO連接兩個數(shù)據(jù)源加載到窗體也行，代碼多一點。我是懶人，不愿意兩個ADO連接了。我這個例子說明有時候綁定與非綁定，都不是問題的根本所在。

4。 大數(shù)據(jù)的處理不管綁定或非綁定，哪種方式效果都不會好。更多的問題反映在系統(tǒng)的架構(gòu)，服務(wù)器的磁盤、磁盤的接口和網(wǎng)絡(luò)等是性能瓶頸了。我們現(xiàn)在的產(chǎn)品BOM應(yīng)用，在大型商業(yè)軟件的性能遠(yuǎn)沒有我們自己開發(fā)的系統(tǒng)性能好，說明一個復(fù)雜系統(tǒng)的性能，最關(guān)鍵還是系統(tǒng)的架構(gòu)要科學(xué)合理。硬件可以通過升級去提高，系統(tǒng)架構(gòu)一旦定下來了，再去修改，跟重新開發(fā)沒多少區(qū)別。

5。 開發(fā)中，我們掌握了用戶的使用情況，比如記錄數(shù)，字段大小，計算的復(fù)雜程度，用戶數(shù)，業(yè)務(wù)流程，服務(wù)器性能，客戶機性能，網(wǎng)絡(luò)等情況，更能開發(fā)出科學(xué)合理的系統(tǒng)出來。這也是為什么很多時候商用軟件不如業(yè)務(wù)人員自己開發(fā)的系統(tǒng)好用的重要原因。ACCESS能如此廣泛使用也跟這些因素有很大關(guān)系吧。

    吃中飯時間到了 。。。。。。。。

lshstruc

補充樓上LAIMF的第三條：
非常贊同樓上的處理辦法，ODBC鏈接表處理純數(shù)據(jù)，根據(jù)我的了解，速度還是挺好的，對于一個表中比較大的字段，不建議放在同一個記錄集中打開，樓上的通過ADO來根據(jù)記錄的主鍵單獨尋找該字段，是一個好辦法。
其實ACC的綁定窗體自身是支持綁定字段以外的控件的，綁定窗體上的控件除了綁定到字段，還可以綁定到表達(dá)式，而這個表達(dá)式是支持與綁定字段的控件聯(lián)動的。
而對于該綁定表達(dá)式控件的值，是根據(jù)綁定字段計算得來的，microsoft的強大就在于，啥都替你想到了，如果你的記錄集中有1000條記錄，他卻不會把1000條記錄對應(yīng)的表達(dá)式全部計算出來，然后放在內(nèi)存里，他是這么處理的：
1.單個窗體：僅根據(jù)窗體當(dāng)前記錄計算對應(yīng)的控件值，跳到下一條記錄，重新計算下一條的控件值，并清除上一條的控件值。
2.連續(xù)窗體和數(shù)據(jù)表窗體：僅計算當(dāng)前屏幕上顯示的記錄對應(yīng)的控件值，通過滾動條滾動到下一頁，重新計算下一頁的控件值，并清除上一頁的控件值。（19寸的屏幕和20寸的屏幕計算的量也是不一樣的，窗口最大化和縮放后計算的量也是不一樣的，很有意思）。
所以完全不用擔(dān)心卡的問題，我沒有處理過圖片的問題，但是我處理過一個“備注”字段，用的也是這種方法：
1.窗體綁定到記錄集，記錄集不包含備注字段。
2.建一個非綁定的控件，直接用ACC自帶的域聚合函數(shù)，控件值=DLOOKUP()，根據(jù)窗體綁定的記錄ID查閱備注字段。
以上方法沒有一句代碼，沒試過圖片，不知能行不。
缺點是DLOOKUP 可能比自己寫的ADO代碼稍微慢，但完全用acc自身功能，基本不寫代碼，簡單，穩(wěn)定，可靠。而且支持?jǐn)?shù)據(jù)表窗體和連續(xù)窗體，自動聯(lián)動，特別適合我這樣的懶人。

zpy2

用dbsqlpassthrouth調(diào)用存儲過程

風(fēng)中漫步

高手如云啊.