Created by Wang, Jerry, last modified on Nov 12, 2015

這段代碼由兩段非常復雜的SQL 查詢語句組成。兩段語句絕大部分都相同，除了下圖的四處。從clean code角度出發，這是dplication。但是由于這里用到的是OPEN SQL，無法把common的部分抽成方法，因為OPEN SQL里的JOIN不支持把table name dynamic 傳進去。

就我的理解，crm_jest_和crm_jsto都是client dependent的表，因此不需要通過CLIENT SPECIFIED顯式指定client。

按照SCN上的說法，指定client和不指定，對性能無任何影響。

我覺的這個IS NULL可以去掉。

ABAP help上說的很清楚：

Please note that the NULL value is inserted only for the existing records, by the time the new field is being inserted. For all new records, SPACE or the initial (default) value is inserted.
If the new field is inserted by checking the checkbox “initial values”, then the initial values (SPACE in case of characters) are automatically inserted and not the NULL values.

而且這個field的initial已經勾上了，因此唯一可能讓IS NULL返回true的condition，

就是ABAP help 里提到的outer join：

但是我看了下source code里的OPEN SQL，里面的操作應該不會造成template field為NULL的結果，所以我覺得這個檢查可以刪除。

這個ABAP open SQL do’s and don’ts 里說

(1) 盡量避免nested select statement

(2) 盡量避免復雜的where語句，否則database optimizer沒法做優化。我們這個代碼里的where語句里又套了嵌套的select，應該算是complex了。

這個還是改成常量space吧：

然后I1004改成released吧：

AG3和QHD都是HANA DB了，即使我們的代碼在上面跑的很快，但是也不能排除如果在客戶的Non HANA DB比如max DB上跑效果如何。一個典型的例子就是ERCO的account search in my appointment，BP底層的SQL是動態生成的，在我們自己的系統上一直沒有遇到過性能問題，這個incident 6月份就報了，到現在BP都沒解決。

最后DB expert分析得出結論現在的SQL 語句在MaxDB下需要重寫。

所以我在想我們有時間的話，能不能先考慮準備另一套方案，就是先設法把where里的nested select去掉，可以換成用多個select順序執行的方式，最后簡單測試下兩個solution的性能。

我去年做聯想的性能評測就是在AG3上做的：

把SQL里所有涉及到的表全部copy一個Z的出來，創建兩個report，把兩種solution的SQL 語句貼到report里，當然table name也要全部換成Z的

在AG3上寫一個report，把每個Z表的每一條數據， 根據需要分別復制一個倍數。比如CRM_MKTPL_ATTR現在有100條，我把每條復制1000次，每次復制的時候重新生成新的guid，其他數據都不變，這樣復制完后我就得到10萬條數據了。

當然這樣做的話要花點時間。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的一个ABAP重构的实例：CL_CRM_LEAD_CREATE~SELECT_CAMPAIGNS_BY_SQL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。