資料庫設計實踐:你不想做的七件事
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