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