Like Share Discussion Bookmark Smile

J.J. Huang   2020-05-16   Java   瀏覽次數:

《阿里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