印尼分分彩app:Java程序員寫SQL程序常犯的10個錯誤

2013-08-05 11:43:57來源:作者:

福彩有极速赛车吗 www.ipmpe.com 當Java程序員寫SQL語句時,一切都不一樣了。SQL是說明性語言而非面向對象或是命令式編程語言。在SQL中要寫個查詢語句是很簡單的。但在Java里類似的語句卻不容易,因為程序員不僅要反復考慮編程范式,而且也要考慮算法的問題。下面是Java程序員在寫SQL時常犯的錯誤:

Java程序員編程時需要混合面向對象思維和一般命令式編程的方法,能否完美的將兩者結合起來完全得依靠編程人員的水準:

  • 技能(任何人都能容易學會命令式編程)
  • 模式(有些人用“模式-模式”,舉個例子,模式可以應用到任何地方,而且都可以歸為某一類模式)
  • 心境(首先,要寫個好的面向對象程序是比命令式程序難的多,你得花費一些功夫)

但當Java程序員寫SQL語句時,一切都不一樣了。SQL是說明性語言而非面向對象或是命令式編程語言。在SQL中要寫個查詢語句是很簡單的。但在Java里類似的語句卻不容易,因為程序員不僅要反復考慮編程范式,而且也要考慮算法的問題。

下面是Java程序員在寫SQL時常犯的錯誤(沒有特定的順序):

1.忘掉NULL

Java程序員寫SQL時對NULL的誤解可能是最大的錯誤。也許是因為(并非唯一理由)NULL也稱作UNKNOWN。如果被稱作UNKNOWN,這還好理解些。另一個原因是,當你從數據庫拿東西或是綁定變量時,JDBC將SQL NULL 和Java中的null對應了起來。這樣導致了NULL = NULL(SQL)和null=null(Java)的誤解。

對于NULL最大的誤解是當NULL被用作行值表達式完整性約束條件時。

另一個誤解出現在對于NULL 在 NOT IN anti-joins的應用中。

解決方法:

好好的訓練你自己。當你寫SQL時要不停得想到NULL的用法:

  • 這個NULL完整性約束條件是正確的?
  • NULL是否影響到結果?

2.在Java內存中處理數據

很少有Java開發者能將SQL理解的很好.偶爾使用的JOIN,還有古怪的union  ,好吧.但是對于窗口函數呢?還有對集合進行分組呢?許多的Java開發者將SQL數據加載到內存中,將這些數據轉換成某些相近的集合類型,然后再那些集合上面使用邊界循環控制結構(至少在Java8的集合升級以前)執行令人生厭的數學運算.

但是一些SQL數據庫支持先進的(而且是SQL標準支持的!)OLAP特性,這一特性表現更好而且寫起來也更加方便.一個(并不怎么標準的)例子就是Oracle超棒的MODEL分句.只讓數據庫來做處理然后只把結果帶到Java內存中吧.因為畢竟所有非常聰明的家伙已經對這些昂貴的產品進行了優化.因此實際上,通過將OLAP移到數據庫,你將獲得一下兩項好處:

  • 便利性.這比在Java中編寫正確的SQL可能更加的容易.
  • 性能表現.數據庫應該比你的算法處理起來更加快.而且更加重要的是,你不必再去傳遞數百萬條記錄了.

完善的方法:

每次你使用Java實現一個以數據為中心的算法時,問問自己:有沒有一種方法可以讓數據庫代替為我做這種麻煩事.

3. 使用union  代替union   ALL

太可恥了,和union  相比union   ALL還需要額外的關鍵字。如果SQL標準已經規定了支持,那么可能會更好點。

  • union  (允許重復)
  • union   DISTINCT (去除了重復)

移除重復行不僅很少需要(有時甚至是錯的),而且對于帶很多行的大數據集合會相當慢,因為兩個子select需要排序,而且每個元組也需要和它的子序列元組比較。

注意即使SQL標準規定了INTERSECT ALL和EXCEPT ALL,很少數據庫會實現這些沒用的集合操作符。

處理方法:
每次你寫union  語句時,考慮實際上是否需要union   ALL語句。

4.通過JDBC分頁技術給大量的結果進行分頁操作

大部分的數據庫都會支持一些分頁命令實現分頁效果,譬如LIMIT..OFFSET,TOP..START AT,OFFSET..FETCH語句等。即使沒有支持這些語句的數據庫,仍有可能對ROWNUM(甲骨文)或者是ROW NUMBER() OVER()過濾(DB2,SQL Server2008等),這些比在內存中實現分頁更快速。在處理大量數據中,效果尤其明顯。

糾正:

僅僅使用這些語句,那么一個工具(例如JOOQ)就可以模擬這些語句的操作。

5.在java內存中加入數據

從SQL的初期開始,當在SQL中使用JOIN語句時,一些開發者仍舊有不安的感覺。這是源自對加入JOIN后會變慢的固有恐懼。假如基于成本的優化選擇去實現嵌套循環,在創建一張連接表源前,可能加載所有的表在數據庫內存中,這可能是真的。但是這事發生的概率太低了。通過合適的預測,約束和索引,合并連接和哈希連接的操作都是相當的快。這完全是是關于正確元數據(在這里我不能夠引用Tom Kyte的太多)。而且,可能仍然有不少的Java開發人員加載兩張表通過分開查詢到一個映射中,并且在某種程度上把他們加到了內存當中。

糾正:

假如你在各個步驟中有從各種表的查詢操作,好好想想是否可以表達你的查詢操作在單條語句中。

6.在一個臨時的笛卡爾積集合中使用 DISTINCT 或 union   消除重復項

通過復雜的連接,人們可能會對SQL語句中扮演關鍵角色的所有關系失去概念。特別的,如果這涉及到多列外鍵關系的話,很有可能會忘記在JOIN .. ON子句中增加相關的判斷。這會導致重復的記錄,但或許只是在特殊的情況下。有些開發者因此可能選擇DISTINCT來消除這些重復記錄。從三個方面來說這是錯誤的:

  • 它(也許)解決了表面癥狀但并沒有解決問題。它也有可能無法解決極端情況下的癥狀。
  • 對具有很多列的龐大的結果集合來說它很慢。DISTINCT要執行ORDER BY操作來消除重復。
  • 對龐大的笛卡爾積集合來說它很慢,還是需要加載很多的數據到內存中。

解決方法:

根據經驗,如果你獲得了不需要的重復記錄,還是檢查你的JOIN判斷吧??贍茉諛掣齙胤接幸桓齪苣丫醪斕牡芽ǘ?。

7. 不使用MERGE語句

這并不是一個過失,但是可能是缺少知識或者對于強悍的MERGE語句信心不足。一些數據庫理解其它形式的更新插入(UPSERT)語句, 如 MYSQL的重復主鍵更新語句,但是MERGE在數據庫中確是很強大,很重要,以至于大肆擴展SQL標準,例如SQL SERVER。

解決之道:

如果你使用像聯合INSERT和UPDATE或者聯合SELECT .. FOR UPDATE然后在INSERT或UPDATE等更新插入時,請三思。你完全可以使用一個更簡單的MERGE語句來遠離冒險競爭條件。

8. 使用聚合函數代替窗口函數(window functions)

在介紹窗口函數之前,在SQL中聚合數據意味著使用GROUP BY語句與聚合函數相映射。在很多情形下都工作得很好,如聚合數據需要濃縮常規數據,那么就在join子查詢中使用group查詢。

但是在SQL:2003中定義了窗口函數,這個在很多主流數據庫都實現了它。窗口函數能夠在結果集上聚合數據,但是卻沒有分組。事實上,每個窗口函數都有自己的、獨立的PARTITION BY語句,這個工具對于顯示報告太TM好了。

使用窗口函數:

  • 使SQL更易讀(但在子查詢中沒有GROUP BY語句專業)
  • 提升性能,像關系數據庫管理系統能夠更容易優化窗口函數

解決方法:

當你在子查詢中使用GROUP BY語句時,請再三考慮是否可以使用窗口函數完成。

9. 使用內存間接排序

SQL的ORDER BY語句支持很多類型的表達式,包括CASE語句,對于間接排序十分有用。你可能重來不會在Java內存中排序數據,因為你會想:

  • SQL排序很慢
  • SQL排序辦不到

處理方法:

如果你在內存中排序任何SQL數據,請再三考慮,是否不能在數據庫中排序。這對于數據庫分頁數據十分有用。

10. 一條一條的插入大量紀錄

JDBC ”懂“批處理(batch),你應該不會忘了它。不要使用INSERT語句來一條一條的出入成千上萬的記錄,(因為)每次都會創建一個新的PreparedStatement對象。如果你的所有記錄都插入到同一個表時,那么就創建一個帶有一條SQL語句以及附帶很多值集合的插入批處理語句。你可能需要在達到一定量的插入記錄后才提交來保證UNDO日志瘦小,這依賴于你的數據庫和數據庫設置。

處理方法:
總是使用批處理插入大量數據。

關鍵詞:JavaSQL