數據庫方面的面試技巧，如何從建表方面展現本身能力

        在面試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千條。也就是說，表之間的關聯代價不會過高，那麼用「三範式」的原則是必需的。畢竟三範式能避免數據冗餘帶來的更新插入上的「須要同時多表裏相同字段」的麻煩。

        第二，若是表的數據量很大，如前面舉的在線購物網站的例子，咱們可能就須要冗餘數據。在訂單流水錶裏，同時放入用戶郵件地址和商品名的字段。

        在獲得「免去鏈接操做」的好處同時，也得付出相應的代價，好比用戶一旦更新了郵件地址，那麼咱們就須要同時在會員表和訂單流水錶裏修改該字段，這就是冗餘帶來的後果。

        

       也就是說，我在詢問如何設計數據表時，我不在意你以前設計過哪些表？關鍵看你在設計表的時候須要考慮哪些因素。

       你們不只須要掌握諸如「鏈接」和「範式」之類的技術，更應該從業務角度，權衡各類「建表代價」，從而挑選一種最符合本項目的解決方案。

        好了，關於建表方面的技能就說到這裏，很簡單，你們一兩分鐘就能看完，但若是你不會說，或者沒說到「權衡」，那麼對不起裏，即便你有過建表經驗，那麼在面試中你沒表現出來，我只能認爲你不熟悉這塊。