一個ABAP重構的執行個體：CL_CRM_LEAD_CREATE~SELECT_CAMPAIGNS_BY_SQL

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萬條資料了。

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