在資料庫正規劃裡，往下一步正規化時，永遠都要遵循前一個正規劃條件，例如今天要介紹第二正規化，在完成第二正規化的同時，也要考慮到是不是符合第一正規化，以此類推，第三、第四......etc都一樣，用圖來表示的話就像這樣：
跟php-fig的coding standard一樣，要滿足前面所有的standard才能往下一階段前進，之後會再介紹。
跟php-fig的coding standard一樣，要滿足前面所有的standard才能往下一階段前進，之後會再介紹。
訂單中都有符合第一正規化的規則，只是在系統真的上線執行之後很快就會發現一個問題：要是顧客的手機或地址換了呢？
這時候我們如果再去撈資料出來改的話，難免會有遺漏，而且費時費力，這時候，就是第二正規化上場的時間了，第二正規化核心規則就是每一個欄位都一定要跟該table的primary key有完全依賴關係，像上圖的table的用途用是存放訂單資料，而member並不是訂單內完全相關的資料，於是我們可以正規化成：
訂單Table:
會員Table:
這樣一來就各自獨立了，每一筆訂單如果有會員，可以直接存放member table的primary key去對應，會員資料變動將會變成非常直觀的事。
如此一來就符合第二正規化了。
今天跟資深工程師討論到正規化，他說其實之前也的確對資料庫做過正規化，但是資料表獨立的結果，就是造成效能的劣化，譬如今天如果一個報表同時需要訂單及詳細的會員資訊，那麼會用到join，而join本身的效能比起直接撈一個很多欄位的table要慢上許多，有的時候要在效能、管理或寫程式的方便性做個取捨，我想這樣的選擇，也是成為一個架構師需要累積經驗的一個必需磨練的道路吧！
參考資料：
沒有留言:
張貼留言