2008-12-19 28 views
4

我正在處理大約3000行代碼中有SQL字符串的項目。如何在源代碼中處理巨大的SQL字符串

該項目是一個java項目,但這個問題可能適用於任何語言。

無論如何,這是我第一次見到這樣糟糕的事情。 代碼庫是遺留的,所以我們可以突然遷移到Hibernate或類似的東西。

你如何處理這樣的大型SQL字符串?

我知道它的壞處,但我不確切知道什麼是最好的解決方案。

回答

10

在我看來,將這些硬編碼值轉換爲存儲過程並引用代碼中的sprocs可能會帶來高收益和低工作量。

2

到目前爲止我所能想到的最好的事情是把查詢放到幾個存儲過程中,就像我要處理一個Java中太長的方法一樣。

+0

幾個存儲過程?這是一個大問題還是這究竟是什麼? – BobbyShaftoe 2008-12-19 22:09:48

+0

絕對有。最大的問題是難以理解。 – 2008-12-19 22:15:10

+0

長大的sql語句沒有任何內在的壞處。如果分解它們並理解這些部分的總和,理解它們並不容易。而且這樣做可能更有效率。任何方式知道它是否被配置/優化? – dkretz 2008-12-19 22:15:33

0

一個簡單的方法是將它們分解成某些常量。這至少會使代碼更具可讀性。

1

我在做的是這樣的:

$ query =「SELECT * FROM table WHERE」; $ query。=「condition < 5 AND」; $ query。=「condition2> 10 AND」;

。 。 。

,然後,一旦你完成分層上$查詢:

的mysql_query($查詢);

3

我想第一個問題是,你在做什麼應該與它做?如果沒有損壞,請悄悄關閉並假裝你從未見過它。否則,像瘋了似的重構 - 希望有某種退出條件,看起來像一個合同。

6

SQL是否有很多變量的字符串連接?

如果沒有,你可以提取他們把它們放在資源文件中。但是,您必須刪除換行符中的字符串聯合。

您使用的存儲過程方法非常好,但有時候當需要了解SQL在做什麼時,必須從工作區切換到您最喜歡的SQL IDE。這是唯一不好的事情。

對於我的建議會是這樣的:

String query = "select ......."+ 
3000 lines. 

ResourceBundle bundle = ResourceBundle.getBundle("queries"); 
String query = bundle.getString("customerQuery"); 

嗯,這是這個想法。

0

我將它們存儲在文件(或資源)中,然後在應用程序啓動時讀取並緩存它們(或者如果它是服務或其他內容,則更改它們)。或者,只需將它們作爲常量或只讀文件放入一個大的舊SqlQueries類中即可。

2

我和你在同一個地方......我的計劃是將SQL拉入項目中的獨立.sql文件,並創建一個實用程序方法來在需要查詢時讀取文件。

string sql = "select asd,asdf,ads,asdf,asdf," 
      + "from asdfj asfj as fasdkfjl asf" 
      + "..........................." 
      + "where user = @user and ........"; 

查詢被倒入一個叫做usageReportByUser.sql
文件和變成這樣的事情。

string sql = util.queries("usageReportByUser"); 

請確保它以文件不能公開訪問的方式完成。

1

我寫了一個toolkit爲此而回,並已在多個項目中使用它。它允許您將查詢放在大多數文本文件中,併爲它們生成綁定和文檔。

檢出this exampleexample use(它幾乎只是一個預編譯語句,編譯爲具有早綁定/類型安全查詢綁定的java類)。

它也生成一些不錯的javadoc,但我目前沒有在線的任何人。

1

我第二次推薦iBatis。至少,您可以從最有可能使用StringBuffer的Java代碼中提取SQL,並將String concat附加到XML中,以便維護。

我爲一個遺留的Web應用程序做了這個,我打開了調試並運行DAO的單元測試,並將生成的每個語句的sql複製到iBatis xml中。工作很順利。

0

我已經成功地將大型動態查詢轉換爲linq查詢。 (1K行+)這非常適合報告在很少數量的表上進行大量動態過濾和動態分組的情況。爲這些表創建一個edmx,您可以編寫出色的強類型組合查詢。

我發現性能實際上有所提高,結果sql變得更簡單了。 我相信你會得到與Hibernate類似的里程 - 除了能夠使用linq ofcourse。但一般來說,如果生成的sql需要高度動態化,那麼它不是一個存儲過程的好候選。在存儲過程中寫入動態sql是兩個世界中最糟糕的。 SQL生成框架將是我首選的方式去這裏。如果你挖掘休眠我認爲這將是一個很好的解決方案。這就是說,如果查詢只是帶參數的簡單字符串,那麼就把它們扔到一個存儲過程中,然後用它來完成。 - 但是,你錯過了很好的結果與物體一起工作。

相關問題