我們的大型應用程序(VB.Net,Framework 3.5)已經或多或少地從一開始就使用SQL Server和SQL Server進行開發。當然有一天有人把它賣給了客戶,並且承諾我們可以使它在Oracle(10g及以上版本)上工作,現在它已經可以,但是我們遇到了相當多的性能問題。使參數化查詢適用於SQL Server和Oracle
這源於以下事實:幾乎全部的SQL(包含在應用程序代碼)的形式是
SELECT Col1, Col2, Col3 FROM TableName WHERE IdCol = @EntityId
這然後被傳遞給我們的數據訪問層連同參數的陣列的參數化查詢名稱,類型數組和數組值,然後使用Enterprise Library 5執行以處理實際的連接等。
當這個項目開始,有人意識到,甲骨文需要在形式
:EntityId
參數和決定,而不是試圖找到並重新編寫SQL的每一點(這個程序就有一百萬LOC還有套件中的其他人),他們將添加一個函數,該函數在執行查詢之前調用,在查詢和參數名稱數組中都將替換爲@:。它還刪除了'WITH NOLOCK',方括號,並取代了串聯字符和SQL Server使用但其他Oracle不使用的其他此類工件。當然,問題在於字符串搜索和替換是昂貴的,並且在應用程序中的一個簡單操作中,有一次按順序執行了超過2000個簡單查詢。針對SQL Server,這根本不需要任何時間,但是對於Oracle平臺,需要20-30秒。
理想情況下,我想重新編寫大量的代碼來清除低效/低效的代碼和設計,並修復不友好的架構,並用nHibernate或Entity Framework來取代很多。但由於商業壓力和任務規模的限制,這種情況不會很快發生。
鑑於我非常不可能被允許做如此巨大的根本性變化切換到ORM或重新架構,大量的代碼,我的問題很簡單:
有沒有一種方法,使無論是SQL Server或Oracle理解另一種參數標識符或一些明智而簡單的方式來以通用的方式編寫參數化查詢,而不需要大量的字符串替換或IF ... Else語句依賴於目標平臺?我意識到我可能仍然需要編輯應用程序中幾乎所有的SQL語句,但是如果是這種情況,那就這樣做吧,我只能把這個想法賣給我的老闆。
乾杯
這很有道理。我們已經在使用EL5了,所以我會看看緩存應用程序塊,如果有幫助的話可以回報。乾杯。 – 2012-03-29 08:27:09
我也建議首先分析您的應用程序,以確保查詢轉換是性能瓶頸。在處理性能問題時開始進行性能分析總是更好的 – Nikolay 2012-03-29 08:41:41
我們已經做到了 - 這就是我們如何知道這是問題的原因!在某些方面,這很好,因爲它有助於識別(並突出顯示管理層)這個應用程序中的一些嚴重的固有設計缺陷,所以他們認真對待它,而不是假設所有關於開發人員都希望「高科技」。 – 2012-03-29 10:32:40