建站
咨詢
售后
建站咨詢
新聞中心
創(chuàng)新互聯(lián)是一家以成都網(wǎng)站建設(shè)公司、網(wǎng)頁設(shè)計、品牌設(shè)計、軟件運(yùn)維、網(wǎng)站推廣、小程序App開發(fā)等移動開發(fā)為一體互聯(lián)網(wǎng)公司。已累計為成都護(hù)欄打樁機(jī)等眾行業(yè)中小客戶提供優(yōu)質(zhì)的互聯(lián)網(wǎng)建站和軟件開發(fā)服務(wù)。
剛做開發(fā)人員的時候，需要掌握的東西非常多。首先是編程語言本身，還有所有你用到的框架的的特定用法，之后(也可能是之前)，前端開發(fā)的東西也會混進(jìn)來，在開發(fā)過程中你還要考慮數(shù)據(jù)存在哪的問題。
起初，由于你有太多東西需要迅速掌握，在應(yīng)用設(shè)計的過程中，會傾向于把數(shù)據(jù)庫放在后面考慮(大概因為它對用戶的使用體驗沒什么影響)。結(jié)果就是在處理數(shù)據(jù)庫的時候，會發(fā)現(xiàn)很多不好的實(shí)踐。這里舉幾個例子。
1. Storing images 儲存圖片
數(shù)據(jù)庫里不應(yīng)該放圖片。你可以做的事情并不代表你就應(yīng)該去做。圖片會占用數(shù)據(jù)庫里相當(dāng)大的空間，吃掉不必要的 IO 資源從而拖慢應(yīng)用。這個錯誤最常出現(xiàn)的情況，就是新人將圖片用 base64 編碼，然后將其儲存在很大的 text/blob 字段當(dāng)中。
更好的辦法是直接將圖片上傳至像 Amazon S3 這樣的云服務(wù)上，然后用數(shù)據(jù)庫里用 text 字段儲存圖片的 URL。每次要加載一張圖片的時候，只要把圖片的 URL 輸出到有效的 標(biāo)簽里就可以了。這會極大地提升網(wǎng)頁的響應(yīng)速度，對大規(guī)模 Web 應(yīng)用非常有幫助。
2. Limit/Offset
分頁在很多應(yīng)用中都非常常見。從你開始學(xué)習(xí) SQL，(你就該知道)最直接的分頁方法就是先用 ORDER BY 對數(shù)據(jù)庫的一些列進(jìn)行排序，然后 LIMIT 返回的結(jié)果數(shù)，對除***頁外的每一頁使用 OFFSET。這看起來很符合邏輯，直到你處理中等規(guī)模應(yīng)用時才意識到：
- 它對數(shù)據(jù)庫施加的負(fù)載是非常痛苦的。
- 它具有不確定性，記錄應(yīng)該隨著用戶翻頁而改變。
不幸的是：分頁非常復(fù)雜，目前還沒有一個萬全之策。
3. 用整數(shù)做 primary key
在創(chuàng)建 primary key 的時候，幾乎所有的 ORM(Object Relational Mapping 對象關(guān)系映射)的默認(rèn)做法都是創(chuàng)建一個串行字段，它是按順序自動生成的，然后你就可以用它(這些自動生成的數(shù)字)作為你的 primary key。在管理員看來，這是非常直觀的，因為可以由用戶 1 到 用戶 2 這樣依次查看。對大多數(shù)的應(yīng)用來說，這種做法通常是不錯的。但是隨著這些整數(shù) primary key 不斷變大，你很快就會意識到處理他們會讓人筋疲力盡。對于大規(guī)模系統(tǒng)，這是很不理想的處理方法。此外，你還會依賴生成這些 key 的那個系統(tǒng)，在你必須要擴(kuò)大規(guī)模的時候，會非常痛苦。更好的解決辦法是從一開始就利用好 UUID (Universally Unique Identifier 通用唯一識別碼)的優(yōu)勢。
(UUID)還有其它的好處，那就是它不會無形中暴露給用戶(數(shù)據(jù)庫中)有多少用戶、列表、或是這些 key 所指代的任何東西。
4. 新列中的默認(rèn)值
無論你做這個工作有多久，都不會一次就創(chuàng)建出一個***的 schema。***是將數(shù)據(jù)庫 schema 視為一個持續(xù)演化的文檔。不幸的是：向數(shù)據(jù)庫中添加一列是件很容易的事，這也就意味著在添加列的時候把工作搞砸同樣很容易。默認(rèn)情況下，如果你新添加了一列，通常是允許有 NULL 值的。這個操作速度很快，但大多數(shù)應(yīng)用實(shí)際上不太想讓他們的數(shù)據(jù)里有 null 值，他們會想要設(shè)置默認(rèn)值。
如果你在表里添加設(shè)置了默認(rèn)值的新列，會對這張表觸發(fā)一次完全的重寫。注意：這對應(yīng)用中的任何(數(shù)據(jù)量)很大的表都非常不利。(正確的方法)恰恰相反，***是先允許 null 值存在，這樣操作就是即時的，接下來再設(shè)置默認(rèn)值，再用后臺進(jìn)程去回溯更新數(shù)據(jù)。
實(shí)際操作比我所說的要更復(fù)雜，幸好已經(jīng)有一些便利的指南可以為我們提供幫助。
5. 過度標(biāo)準(zhǔn)化
開始學(xué)習(xí)數(shù)據(jù)庫的標(biāo)準(zhǔn)化的時候，(標(biāo)準(zhǔn)化)感覺就像是很正確的事。你創(chuàng)建了一個 posts 的表，里面包含 authors，每篇文章(post)都屬于一個條目(category)，所以你又創(chuàng)建了一個 categories 的表，然后再創(chuàng)建一個把它們倆 join 在一起的表，post_categories。從根本上來說，這樣做標(biāo)準(zhǔn)化也沒什么原則上的錯誤，但是某種程度上，標(biāo)準(zhǔn)化的收益正在遞減。
在上述實(shí)例中，categories 可以簡單地作為 post 里的一個 varchar 字段。標(biāo)準(zhǔn)化是件很有意義的工作，但是每次處理包含多對多關(guān)系的表時都要深思熟慮，想想你是不是真的需要在關(guān)系的兩邊都各用一個單獨(dú)的表。
修正：值得一提的是，欠標(biāo)準(zhǔn)化也是個問題。這里并不存在“一刀切”的解決方案。有時完全不做標(biāo)準(zhǔn)化和完全標(biāo)準(zhǔn)化也行得通。像 @fuzzychef 說的那樣：“適度標(biāo)準(zhǔn)化，即金發(fā)姑娘原則(The goldilocks principle，意為適度的是***的)”。
總結(jié)
在 Twitter 上問到這個問題的時候，我得到了很多非常棒的回應(yīng)，但是這些回應(yīng)五花八門。從“從不查看 ORM 生成的查詢”這樣的基本問題，到像事務(wù)隔離這樣的進(jìn)階話題。有一點(diǎn)我并沒提到，但是對于所有構(gòu)建 app 的人來說都非常值得注意的一點(diǎn)就是索引。了解索引的工作原理，知道你需要創(chuàng)建什么樣的索引，是獲得良好的數(shù)據(jù)庫性能的關(guān)鍵。除了用 Postgres 分析性能的實(shí)踐步驟以外，還有很多關(guān)于索引的基礎(chǔ)知識的文章。
通常我會鼓勵大家把數(shù)據(jù)庫當(dāng)做你工具箱中的另一個工具，而不是什么非學(xué)不可的惡魔。但我希望，以上的提示可以幫助初學(xué)者避免一些基本錯誤。
文章標(biāo)題：數(shù)據(jù)庫新手常犯的5個錯誤
分享鏈接：http://www.5511xx.com/article/cdidcij.html
