[[199956]]

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

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

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 分析性能的實踐步驟以外，還有很多關于索引的基礎知識的文章。

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