阿里巴巴Java開發手冊———我的追加的看法和補充（三）

前言

若是你沒有看過以前的（一）或者沒有下載這份手冊的話，下面有連接，仍是對照手冊食用畢竟好。

http://www.cnblogs.com/linkstar/p/6413402.html

（二）的地址在下面，是關於異常和日誌的。

http://www.cnblogs.com/linkstar/p/6415788.html

手冊我特意在博客園文件中放了一份在線的僅供參考（由於好像發現最上面那個地址須要登陸。。。）

http://files.cnblogs.com/files/linkstar/%E9%98%BF%E9%87%8CJava%E7%BC%96%E7%A8%8B%E8%A7%84%E8%8C%83.pdf

該說的我以爲（一）裏面我都說完了，那麼就直接進入正題吧。

 

Mysql規約

照例先講廢話：

mysql做爲開源的數據庫，由於其大小和功能等一直被人們所喜歡，因此用的人比較多，學習時咱們也常用，對於小型項目來講，mysql不少時候已經足夠用了，因此這裏阿里給出的也是mysql的規範，對於其餘的數據庫來講也是同樣的。可是，對於數據庫的表名，字段名，sql語句，這些的規範對於設計數據庫和開發來講是十分重要的，由於數據庫和代碼不一樣，代碼能夠修改，可是數據庫的修改真的是「牽一髮而動全身」，因此開發前仍是仔細斟酌。

廢話完了。

在下面先講一個重點：MySQL中的數據庫名和表名和操做系統有關，在windows操做系統中，不區分大小寫，在unix ，linux操做系統中，是區分大小寫的。這個坑我是被踩過的，就是由於命名不規範的緣由，有人在命名錶的時候使用了大寫字母（實際產生的表的名字仍是小寫），並且在sql語句中使用的也是大寫字母，由於開發是在windows平臺，一切正常，由於大小寫不區分，因此執行的時候，大寫字母自動變成小寫，可是以後一到linux服務器上面，就炸炸炸！！！因此這就是爲何表的名字必須使用小寫和下劃線的緣由。

 

建表規約

一、不少人會奇怪爲何會有這一條，我補充一句，合適的數據類型能夠在省空間的同時避免你不少的錯誤。再附贈一張mysql數據類型和java數據類型對應的表，這張表挺好用的，等到你用多了以後，天然就能熟練對應了。

 

六、float和double在使用時會出現精度丟失的狀況，使用decimal不會，可是要注意的是decimal的範圍是你本身設置的，在平時的使用中儘可能準確去估計你要使用的大小，（暫時尚未decimal不夠用的狀況）

 

九、自增id就不說了，惟一性約束，主要是說明一下gmt_create和gmt_modified字段，一開始看，我懵逼了，這是啥，也沒說明是什麼，後面想一想一個是建立時間，一個是修改時間，gmt是格林尼治標準時間….好吧，我也有點醉醉的。我的認爲是這樣的，首先添加時間對於不少來講是須要的，對於不少業務來講很重要，而修改時間是爲了後期萬一出現問題反查數據檢錯用的。目前修改時間在個人項目中用的並很少，添加時間卻是幾乎都有，以後會考慮加入修改時間，可是並不是強制。

 

十二、數據庫不寫註釋的人，一抓一大把，真的是，每次去維護一箇舊的項目，就會發現不寫數據庫註釋的，你不寫數據庫註釋對於別人來講，那麼對於字段名錶名將一臉懵逼。因此要養成良好的習慣，註釋並不是只有在代碼中寫的。

 

索引規約

千萬不要忽視索引的重要性，一個數據庫有沒有索引查詢的效率是很是不同的，由於不少時候咱們剛開始學習數據庫的時候，可能索引只存在於課本或者視頻，實際中感受好像沒用，其實主要緣由是數據量小的時候你根本感受不出沒有索引的查詢時有多麼的慢，因此索引的重要性就要注意咯。

二、join，錶鏈接是很是影響性能的，我曾經看到，一個設計很是很差的數據庫交到一個程序員手裏，結果這個程序員是個真碼農，寫了一個11張錶鏈接的查詢，結果可想而知，連在不大的數據狀況下，打開頁面都要1分鐘。因此儘量的連的少。

 

四、有人可能奇怪這一條，爲何左模糊或者全模糊都不行，那麼右模糊是否能夠呢？右模糊可使用，爲何別的不行呢？由於別的效率真的很低，左模糊和全模糊的查詢效率在數據量大的時候很慢，比右模糊要慢的多。

$sql1 = "...... title like someTitle%" (花費0.001秒)
$sql2 = "...... title like %someTitle%" (花費0.8秒)

 

七、總結一句話，在寫sql的時候，儘量的先將容易被篩選的條件和那些能夠去除掉不少不須要數據的條件先寫（也就是第九條也提到的），使查詢加快。延遲關聯是也就是指，先加條件查詢掉那些條件以後再去關聯別的表去查詢所有的數據，而不是關聯以後再去查。

 

八、這條要求可能就比較嚴格了，做爲我來講，暫時尚未那麼數據量大的級別的項目須要進行全部的sql的優化，我只是對於那些訪問量極高的，一個項目裏面也就那麼幾個極其重要的sql進行特定的優化，主要也是優化查詢的性能。對於sql性能優化來講，這種事情仍是須要專業的DBA的，畢竟人家是吃這碗飯的，本身想到優化的點仍是太少，網上有不少sql優化的講述，我這裏就很少說了。

 

SQL規約

三、sum還有max等函數，當使用這些函數進行查詢的時候必定要注意，返回的多是null，不過個人作法和手冊給出的不一樣，由於在個人想法中數據庫儘可能是不能放邏輯代碼的（後面我也會說到），當遇到這種狀況時，我會使用包裝類來接受數據庫返回的結果，由於普通的int是不能爲null的，由於是基本類型，而包裝類Integer是能夠爲null，而後你只須要對這個對象進行判空便可，這樣邏輯就存在於java代碼中了。

 

六、不少學生，特別是學生，常常有疑問的就是，我在學校裏面學習數據庫的時候，老師經常交咱們外鍵是什麼，表裏面外鍵是哪一個，可是開發中歷來不會有人跟你說外鍵，爲何？緣由就在這裏，外鍵形成的影響，首先是使表的狀況你不可控，有時你徹底不知道數據變化會致使怎麼樣的結果，還有就是影響數據庫的性能，數據庫每次都要管理你的外鍵，每次的插入還要去判斷外鍵，等等，不少性能都浪費了，不少的約束和保證都已經由索引來完成了。

 

七、我並非很是認同這個觀點，至少我認爲併發強制，緣由是這樣的，存儲過程確實須要面對各類各樣的問題，可是並不能一棒子打死，在某些特殊的地方，舉個極端的例子，若是要運行的是1M的sql，而網絡帶寬還特別差，還要求你運行速度高，這樣的狀況下就可使用存儲過程，由於存儲過程的sql是存放在服務器上面的，不須要經過網絡進行傳輸，在網速不好的狀況下也能有很高的速度，雖然這個例子可能有點極端，可是我想說明的就是這樣一個意思，即便我到如今爲止只用過一次，可是並不能說永遠都不使用了。

 

十、表情使用utfmb4

 

ORM規約

一、只有懶惰的像豬的程序員才用select *

 

八、修改你須要的字段，不要的字段不要去修改

 

九、不要在類上面寫@Transactional，我見過不少人偷懶，直接在類上面寫@Transactional，這樣致使這個類的每個方法都採用了事務，可是實際上，不少時候是不須要事務的。

須要使用事務的狀況：1、屢次修改不一樣的數據。2、屢次刪除不一樣的數據。3、多種操做間存在關聯性，前面操做失敗會直接致使後面出現問題，且前面的操做不回滾會出現髒數據的狀況。

事務是很影響執行時間的，因此要慎用，也要用的好。

 

總結和補充

這裏還有幾點須要補充的，這裏沒有提出觸發器的問題，這個也是不少人問過個人，個人回答是，觸發器不到萬不得已不要使用，由於這東西和外鍵是同樣同樣的，不少時候都是會讓你不可控制，並且維護起來很是難。還有就是數據庫必定要備份。有bug不怕，一旦數據出問題，並且數據庫恢復不出來的話，那就神也救不回來了。新聞也報道過不少次數據庫的意外，特別是遊戲的。

總之對於數據庫，咱們要學習的還有不少。我以爲手冊的總結也是對於開發來講的，對於DBA可能要求比這個要多的多。因此若是你是DBA的話可能要了解的更加深刻才行哦。