《阿里Java開發手冊》 | MySQL 資料庫 - ORM映射

【強制】在表查詢中，一律不要使用 * 作為查詢的欄位列表，需要哪些欄位必須明確寫明。
說明：

• 增加查詢分析器解析成本。
• 增減欄位容易與 resultMap 配置不一致。
• 無用欄位增加網路消耗，尤其是 text 類型的欄位。

【強制】POJO 類的布林屬性不能加 is，而資料庫欄位必須加 is_，要求在 resultMap 中進行欄位與屬性之間的映射。
說明：參見定義 POJO 類以及資料庫欄位定義規定，在 sql.xml 增加映射，是必須的。

【強制】不要用 resultClass 當返回參數，即使所有類屬性名與資料庫欄位一一對應，也需要定義 <resultMap>；反過來，每一個表也必然有一個 <resultMap> 與之對應。
說明：配置映射關係，使欄位與 DO 類解耦，方便維護。

【強制】sql.xml 配置參數使用：#{}、#param## 不要使用 ${} 此種方式容易出現 SQL 注入。

【強制】iBATIS 自帶的 queryForList(String statementName,int start,int size)不推薦使用。
說明：其實作方式是在資料庫取到 statementName 對應的 SQL 語句的所有記錄，再通過 subList 取 start,size 的子集合。
正例：

1
2
3

Map<String, Object> map = new HashMap<>();
map.put("start", start);
map.put("size", size);

【強制】不允許直接拿 HashMap 與 Hashtable 作為查詢結果集的輸出。
反例：某同學為避免寫一個 <resultMap> ，直接使用 HashTable 來接收資料庫返回結果，結果出現日常是把 bigint 轉成 Long 值，而線上由於資料庫版本不一樣，解析成 BigInteger，導致線上問題。

【強制】更新資料表記錄時，必須同時更新記錄對應的 gmt_modified 欄位值為當前時間。

【推薦】不要寫一個大而全的資料更新接口。傳入為 POJO 類，不管是不是自己的目標更新欄位，都進行 updatetablesetc1=value1,c2=value2,c3=value3; 這是不對的。執行 SQL 時，不要更新無改動的欄位，因為：

• 易出錯。
• 效率低。
• 增加 binlog 存儲。

【參考】@Transactional 事務不要濫用。事務會影響資料庫的 QPS，另外使用事務的地方需 要考慮各方面的回滾方案，包括緩存回滾、搜索引擎回滾、消息補償、統計修正等。

【參考】<isEqual> 中的 compareValue 是與屬性值對比的常數，一般是數字，表示相等時帶上此條件； <isNotEmpty> 表示不為空且不為 null 時執行；<isNotNull> 表示不為 null 值時執行。

心得

看完這篇「ORM映射」後，歸類幾個重點；不要使用「*」查詢，這是基本的，因為很浪費效能；每個表必定要做resultMap的映射；POJO 類不要大而全，容易出錯效率低，造成log過大。

基本上遵照上面幾點，就可以避免掉很多的問題了。

結語

文章越看越多，技術越學越多，就會發現自己的不足；技術學到後面都會想要將基礎再重新在打得更加扎實。

以前在開發覺得理所當然的事情，例如：命名規則、命名規範，照著別人怎麼說就怎麼做的想法，並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀，書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明；我相信在閱讀完這一系列後，一定會更加扎實且實在。

如對此書有興趣，建議去購買官方認證的書籍，給予官方支持。

註：如有侵權，通知即刪。

註：以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version