在面試java web方面的高級程序員時，我一定會問到 jave core，java web（比如Spring MVC，Hibernate等）和數據庫相關問題。在數據庫方面，對於java 高級程序員而言，不僅需要會基本的增刪改查，而且需要具備一定的“優化”方面的技能。
優化是個大話題，可以從索引，建表和SQL 調優（SQL Tuning）方面入手，這個我們來分析下建表時需要注意的優化點。
我一般會問候選人，“你有沒有設計過數據表？”，大多數回答是設計過，接着我會比較陰險地問下：“你在設計表時是否用到了三泛式”？
很多計算機專業的候選人往往會隨口回答“是”。這時我就不細問了，同時給候選人寫下如下的評語，“該候選人有基本的數據庫操作的技能，會增刪改查操作，但缺乏專業的數據表設計的能力”。
好了，先來看下三泛式的概念：在第三范式里， 數據不能存在傳遞關系。
比如有張訂單流水表，其中包括（訂單編號，商品編號，下訂單的會員編號，商品名，商品價格，會員姓名，會員手機，會員地址）這些信息。
在這個表里，就存在兩個個傳遞關系。從商品編號能看到商品價格商品名等信息，從下訂單的會員編號能看到會員姓名，手機和地址的信息，所以不符合三泛式 。
如果要按經典學院派的三泛式，我們得把這個表拆分成如下3個表。
| 訂單流水表 |
至少包含訂單編號、商品編號和下訂單的會員編號 |
假設過去1個月有100萬條 |
| 商品表 |
至少包含商品編號和商品名 |
假設過去一個月有50萬條商品信息 |
| 會員表 |
至少包含會員編號會員手機會員地址 |
假設過去一個月里有10萬名會員下過訂單 |
先說下這樣拆分的好處（也就是三泛式）的好處，那就是沒數據冗余，假設之前的訂單流水表包括（訂單編號，商品編號，下訂單的會員編號，商品名，商品價格，會員姓名，會員手機，會員地址），而與此同時，一定也有張商品表和會員表，這樣“商品名“就冗余了（出現在訂單流水表和商品表里），“會員姓名“等字段也冗余了（同時也出現在會員表里）。
這樣做，萬一我們得修改會員手機，那么就得到兩個表里同時修改，增加了工作量不算，而且還增加了出錯的風險（萬一哪個表忘記修改了，數據會不一致）。
看上去三泛式很美，但是（很多事情就壞在但是之后），萬一在一個大型系統里（比如某寶），數據量很大，就如按上表給出的數據量。那么如果我要執行一個非常基本的需求，要列出過去一個月里所有買過Java書籍的會員的郵箱，以便我們發些推薦郵件。
這句SQL語句不復雜，但關鍵是得“關聯”，我們可以用訂單流水表 left join商品表 on 訂單流水表的商品編號 = 商品表的商品編號，在left join 會員表 on 訂單流水表的會員編號 = 會員表的會員編號。
關聯是要代價的，這里我們就得做三張大表之間做關聯，哪怕我再做優化，再利用到數據庫系統的優化（比如用盡Oracle里的優化配置），但由於三個表比較大，關聯的樣本就大了。
這時，如果我們來看下“比較丑”的做法，就一開始把所有字段寫到一個表里。
訂單流水表 =（訂單編號，商品編號，下訂單的會員編號，商品名，商品價格，會員姓名，會員手機，會員地址）
那么由於不需要關聯，性能就很顯著提升。
從這個案例中，大家一定能看到，如果某候選人告訴我設計表時都得遵循三泛式，那么我給出的“沒設計過數據表”也沒冤枉他。
那么關於設計數據表方面，大家該怎么展示自己的能力呢？分類討論。
第一，如果在設計的時候，已經明確地知道這個系統的數據量不會太大，比如一個中學的圖書管理系統，最多有5萬條書本的數據，過去一個月里借閱記錄不會超過1千條。也就是說，表之間的關聯代價不會太高，那么用“三范式”的原則是必需的。畢竟三范式能避免數據冗余帶來的更新插入上的“需要同時多表里相同字段”的麻煩。
第二，如果表的數據量很大，如前面舉的在線購物網站的例子，我們可能就需要冗余數據。在訂單流水表里，同時放入用戶郵件地址和商品名的字段。
在得到“免去連接操作”的好處同時，也得付出相應的代價，比如用戶一旦更新了郵件地址，那么我們就需要同時在會員表和訂單流水表里修改該字段，這就是冗余帶來的后果。
也就是說，我在詢問如何設計數據表時，我不在乎你之前設計過哪些表？關鍵看你在設計表的時候需要考慮哪些因素。
大家不僅需要掌握諸如“連接”和“范式”之類的技術，更應該從業務角度，權衡各種“建表代價”，從而挑選一種最符合本項目的解決方案。
好了，關於建表方面的技能就說到這里，很簡單，大家一兩分鍾就能看完，但如果你不會說，或者沒說到“權衡”，那么對不起里，即使你有過建表經驗，那么在面試中你沒表現出來，我只能認為你不熟悉這塊。