資料庫設計實踐：你不想做的七件事
21CTO導讀：如果你正在設計資料庫，那麼讓我們看一下您不想做的七件事情有哪些。
你的資料庫設計太糟糕？沒人告訴你這個原因是什麼？它有兩個原因：無知與冷漠。他們要麼不知道這是不好的，要不根本不在乎。
作為15年的資料庫專家，我看到太多形形色色的資料庫設計，有好的，有不好的，大多數時間我想罵人。
每當我看到一個不太好的資料庫設計時，我問我自己：這些資料怎麼能得到如此不好的待遇呢？資料處理的時間可能長於程式碼，因此應該對其進行處理。
因此，我希望每位開發者能尊重資料庫設計的過程。在本文中我嘗試指出你做錯了什麼，相信你以後會感謝我的。
以下，是在資料庫設計中你不願意做的七件事。
1 自己動手
就像看牙科一樣，資料庫設計最好留給專業人士，而不是你自己去做的事情。我不在乎你是否能在最後用一個花哨的鏡子拿到其中一個探頭，你應該停止在嘴裡塞一些鋒利的東西。
不能因為你可以做某事，但並不意味著你就可以做好。如果之前你沒有設計過資料庫，那麼就不要將任務的關鍵作為您的第一個專案，請出去聘請專家來幫助你。
我認為迪爾.伯特總結得很好，如下圖：
2 沒有表現期望（或者沒有期望）
我參與了多個專案，根本沒有任何績效期望，直接投入生產環境時表現得“非常慢”。如果沒有定義可接受的效能水平，在後面幾個月中，你會很難放鬆。最終的結果是，我們雖然部署了系統，但是沒有人會對這個過程感到滿意。
如果沒有對效能做預期，會在部署的早期就會出現一些令人頭疼的問題。同樣，如果你對效能有很大的期望，相信會遇到一些失望。如果你沒有做任何的壓力測試，有可能出現非預期的表現。
3 列設定的寬些，以防萬一
我們也會經常看到資料型別被隨意設定，似乎 它們無關緊要。
但是事實是（你可能在大學時被告知這一切）範圍很重要。如果我們知道某個列的值可能值介於0到100,000之間，那麼使用INT型別完全正常，不需要為該列設定成一個BIGINT資料型別。
為什麼這很重要？BIGINT資料型別需要8個位元組的儲存空間，而INT只需要4個位元組就可以。如果用了BIGINT，相當對於每行資料浪費4個位元組。
嗯，聽起來也不是很多，對嗎？
那麼，讓我們思考一下，如果你的表有兩百萬行記錄。將這些行乘以4個位元組，就有800萬字節或大約7.8MB的空間浪費。我知道聽起來還不是很多，對嗎？好吧，它加起來會很快。我只向你展示了一個列的一個例子，比如日期型別的欄位如何？如果不需要在1900年之前或2079年之後的日期，那麼使用SMALLDATETIME很可能更有用。哦，不要忘記這些欄位可以編入索引，這些索引也會不必要地加寬。
我們總結以上這些原因，提醒大家選擇正確的資料型別很重要。花點時間，努力在開始時把事情就做正確。
4 不檢查外來鍵作為索引的一部分
當然，我會假設你已經定義了外來鍵。我見過不少資料庫，幾乎沒有主鍵，外來鍵，甚至沒有定義任何索引。我不知道他們為什麼這麼做，但是人們肯定會找到這些問題。
如果你定義了外來鍵，你應該評估，看看新增索引匹配外來鍵是否有用，在一些情況下，這是有用的。
因此，應該將外來鍵稽核作為資料庫設計的一部分。
5 索引每個列或不索引某個列
假設你已經設定了一些實際的效能要求，應該考慮建立索引。
大多數情況下，我看到資料庫中使用太多的索引，這通常是使用索引工具引發的結果。大多數的文章都會提示你，索引是需要的，我們會建立十幾個索引讓一個查詢執行得更快。
雖然索引非常適合幫助我們更快的讀取資料，但它也會有一些副作用，會增加DUI（刪除、更新、插入）語句的開銷，如果表中的每個列都被添加了索引，那麼任何資料插入表中時，都會增加系統的寫入效能開銷。
6 忘記資料質量
作為一名專業DBA，我知道我的角色一部分是專注於恢復。如果系統出現故障，我需要快速恢復資料，這是我關注的主要關鍵點。而資料庫設計人員不用擔心資料的恢復，而要把焦點關注在資料的完整性上來。
當你在設計資料時，需要確保考慮了資料質量。我們不能指望別人幫你這樣做，想象一下，如果DBA期望其它人恢復資料，這是不可想象的事。事實上，我看到很多垃圾資料進入，垃圾出的資料庫系統。
有很多方法強制執行某種型別的資料完整性。規範化正規化只是一種方式，另一種方法是部署資料質量服務（網址： ofollow,noindex" target="_blank">https://docs.microsoft.com/en- ... -2017 ），它會幫我們執行一定級別的資料質量的規則與約束。
7 沒有資料備份與儲存策略
我願意打賭你現在沒有超過七年的資料。無論系統如何升遷，七年的資料似乎神話一般。如果你問某人他們需要多長時間儲存系統的記錄，答案就是“七年”，即使真正的答案只有七週。
在資料庫系統設計時要考慮一件事：始終在表中儲存和儲存好。
在設計資料庫時，需要花時間計算將保留多少資料。知道這些資訊可以幫助在佔用空間越來越大的資料，預測效能和磁碟的預期。
小結
以上是我看到的好資料庫如何變成糟糕資料庫設計的幾件事。如果你發現正在做這七件事中的任何一件事，隨著時間的推移，資料庫可能會越來越不好處理，同時降低效能。一起做好這七件事，與大家共勉。
編譯：李維剛
來源：21CTO