1. 程式人生 > >資料庫新手常犯的5個錯誤

資料庫新手常犯的5個錯誤

剛做開發人員的時候,需要掌握的東西非常多。首先是程式語言本身,還有所有你用到的框架的的特定用法,之後(也可能是之前),前端開發的東西也會混進來,在開發過程中你還要考慮資料存在哪的問題。

起初,由於你有太多東西需要迅速掌握,在應用設計的過程中,會傾向於把資料庫放在後面考慮(大概因為它對使用者的使用體驗沒什麼影響)。結果就是在處理資料庫的時候,會發現很多不好的實踐。這裡舉幾個例子。

1. Storing images 儲存圖片

資料庫裡不應該放圖片。你可以做的事情並不代表你就應該去做。圖片會佔用資料庫裡相當大的空間,吃掉不必要的 IO 資源從而拖慢應用。這個錯誤最常出現的情況,就是新人將圖片用 base64 編碼,然後將其儲存在很大的 text/blob 欄位當中。

更好的辦法是直接將圖片上傳至像 Amazon S3 這樣的雲服務上,然後用資料庫裡用 text 欄位儲存圖片的 URL。每次要載入一張圖片的時候,只要把圖片的 URL 輸出到有效的 <img> 標籤裡就可以了。這會極大地提升網頁的響應速度,對大規模 Web 應用非常有幫助。

2. Limit/Offset

分頁在很多應用中都非常常見。從你開始學習 SQL,(你就該知道)最直接的分頁方法就是先用 ORDER BY 對資料庫的一些列進行排序,然後 LIMIT 返回的結果數,對除第一頁外的每一頁使用 OFFSET。這看起來很符合邏輯,直到你處理中等規模應用時才意識到:

  1. 它對資料庫施加的負載是非常痛苦的。
  2. 它具有不確定性,記錄應該隨著使用者翻頁而改變。

不幸的是:分頁非常複雜,目前還沒有一個萬全之策。

3. 用整數做 primary key

在建立 primary key 的時候,幾乎所有的 ORM(Object Relational Mapping 物件關係對映)的預設做法都是建立一個序列欄位,它是按順序自動生成的,然後你就可以用它(這些自動生成的數字)作為你的 primary key。在管理員看來,這是非常直觀的,因為可以由使用者 1 到 使用者 2 這樣依次檢視。對大多數的應用來說,這種做法通常是不錯的。但是隨著這些整數 primary key 不斷變大,你很快就會意識到處理他們會讓人筋疲力盡。對於大規模系統,這是很不理想的處理方法。此外,你還會依賴生成這些 key 的那個系統,在你必須要擴大規模的時候,會非常痛苦。更好的解決辦法是從一開始就利用好 UUID (Universally Unique Identifier 通用唯一識別碼)的優勢。

(UUID)還有其它的好處,那就是它不會無形中暴露給使用者(資料庫中)有多少使用者、列表、或是這些 key 所指代的任何東西。

4. 新列中的預設值

無論你做這個工作有多久,都不會一次就創建出一個完美的 schema。最好是將資料庫 schema 視為一個持續演化的文件。不幸的是:向資料庫中新增一列是件很容易的事,這也就意味著在新增列的時候把工作搞砸同樣很容易。預設情況下,如果你新添加了一列,通常是允許有 NULL 值的。這個操作速度很快,但大多數應用實際上不太想讓他們的資料裡有 null 值,他們會想要設定預設值。

如果你在表裡新增設定了預設值的新列,會對這張表觸發一次完全的重寫。注意:這對應用中的任何(資料量)很大的表都非常不利。(正確的方法)恰恰相反,最好是先允許 null 值存在,這樣操作就是即時的,接下來再設定預設值,再用後臺程序去回溯更新資料。

實際操作比我所說的要更復雜,幸好已經有一些便利的指南可以為我們提供幫助。

5. 過度標準化

開始學習資料庫的標準化的時候,(標準化)感覺就像是很正確的事。你建立了一個 posts 的表,裡面包含 authors,每篇文章(post)都屬於一個條目(category),所以你又建立了一個 categories 的表,然後再建立一個把它們倆 join 在一起的表,post_categories。從根本上來說,這樣做標準化也沒什麼原則上的錯誤,但是某種程度上,標準化的收益正在遞減。

在上述例項中,categories 可以簡單地作為 post 裡的一個 varchar 欄位。標準化是件很有意義的工作,但是每次處理包含多對多關係的表時都要深思熟慮,想想你是不是真的需要在關係的兩邊都各用一個單獨的表。

修正:值得一提的是,欠標準化也是個問題。這裡並不存在“一刀切”的解決方案。有時完全不做標準化和完全標準化也行得通。像 @fuzzychef 說的那樣:“適度標準化,即金髮姑娘原則(The goldilocks principle,意為適度的是最好的)”。

總結

在 Twitter 上問到這個問題的時候,我得到了很多非常棒的迴應,但是這些迴應五花八門。從“從不檢視 ORM 生成的查詢”這樣的基本問題,到像事務隔離這樣的進階話題。有一點我並沒提到,但是對於所有構建 app 的人來說都非常值得注意的一點就是索引。瞭解索引的工作原理,知道你需要建立什麼樣的索引,是獲得良好的資料庫效能的關鍵。除了用 Postgres 分析效能的實踐步驟以外,還有很多關於索引的基礎知識的文章。

通常我會鼓勵大家把資料庫當做你工具箱中的另一個工具,而不是什麼非學不可的惡魔。但我希望,以上的提示可以幫助初學者避免一些基本錯誤。