程序中經(jīng)常需要在一個主鍵范圍內(nèi)進行子查詢,而這個范圍是在前臺中動態(tài)生成的,所以傳過來的只能是一個字符串格式的確定這個主鍵范圍的sql語句.以前的做法是在sp中再根據(jù)這個sql語句拼出來返回最終結(jié)果的更大的語句.發(fā)現(xiàn)這樣子的語句往往效率很低,而且數(shù)據(jù)庫的改動(例如列名)也往往無法在包編譯時被檢查出來.解決的思路是先把這個主鍵范圍的值查詢出來,再用這個查詢的結(jié)果和其他的表作鏈接,這樣最終的sql就不再是字符串格式了.因為主鍵范圍相對比較小,效率也會提高很多.于是求助于Oracle的臨時表,這看起來是存放主鍵查詢結(jié)果的理想的地方. 首先想到的是事務型的,但是發(fā)現(xiàn)在前臺的.Net程序執(zhí)行了存儲過程之后,默認執(zhí)行了commit操作,所以返回的結(jié)果都是'對象已經(jīng)不存在'.還沒有搞懂游標的返回機制,但這看起來有些釜底抽薪的意思.因此轉(zhuǎn)而投奔會話型的,查詢的結(jié)果在事務完成后仍會予以保留,只要連接沒有斷調(diào) -- 這在我們這個C/S架構(gòu)的程序中是可以滿足的. 一個新的問題又出來的,就是如何保證兩次執(zhí)行不會發(fā)生影響. 現(xiàn)在的做法是簡單的在每次執(zhí)行前truncate掉臨時表,這樣,每一次執(zhí)行時候,存儲過程所看到的都是一張空表. 至此,大部分的問題便以這種頗為怪異的方式解決了.但是問題仍然是有的.就是并發(fā)的問題.因為是C/S架構(gòu),當前每一個連接是局限在一個客戶端內(nèi),而在同一個客戶端產(chǎn)生這類并發(fā)的機會相對較小(不是沒有).剛剛想到一個可能的思路是每一次查詢完畢后,先去到數(shù)據(jù),然后立即關閉連接,這樣臨時表中的數(shù)據(jù)就會被自動截斷.明天去試一試.一段小插曲,一個哥們在網(wǎng)上搜oracle臨時表相關的材料,發(fā)給我一段類似下面的代碼:declare @table1 Table (cust_id int not null)insert into @table1 select cust_id from customer總覺得看著眼熟,但是在oracle中怎么編譯都不通過.一直到我把目光盯住了那個@ ..... 我終于明白了,這個是SqlServer中的代碼,ft啊,半年不用就退化到這個地步了