剛做開發人員的時候，需要掌握的東西非常多。首先是程式語言本身，還有所有你用到的框架的的特定用法，之後（也可能是之前），前端開發的東西也會混進來，在開發過程中你還要考慮資料存在哪的問題。
起初，由於你有太多東西需要迅速掌握，在應用設計的過程中，會傾向於把資料庫放在後面考慮（大概因為它對使用者的使用體驗沒什麼影響）。結果就是在處理資料庫的時候，會發現很多不好的實踐。這裡舉幾個例子。
1. Storing images 儲存圖片
資料庫裡不應該放圖片。你可以做的事情並不代表你就應該去做。圖片會佔用資料庫裡相當大的空間，吃掉不必要的 IO 資源從而拖慢應用。這個錯誤最常出現的情況，就是新人將圖片用 base64 編碼，然後將其儲存在很大的 text/blob 欄位當中。
更好的辦法是直接將圖片上傳至像 Amazon S3 這樣的雲服務上，然後用資料庫裡用 text 欄位儲存圖片的 URL。每次要載入一張圖片的時候，只要把圖片的 URL 輸出到有效的 <img> 標籤裡就可以了。這會極大地提升網頁的響應速度，對大規模 Web 應用非常有幫助。
2. Limit/Offset
分頁在很多應用中都非常常見。從你開始學習 SQL，（你就該知道）最直接的分頁方法就是先用 ORDER BY 對資料庫的一些列進行排序，然後 LIMIT 返回的結果數，對除第一頁外的每一頁使用 OFFSET。這看起來很符合邏輯，直到你處理中等規模應用時才意識到：
- 它對資料庫施加的負載是非常痛苦的。
- 它具有不確定性，記錄應該隨著使用者翻頁而改變。
不幸的是：分頁非常複雜，目前還沒有一個萬全之策。關於處理分頁問題的更多資訊，你可以參考這些方案。
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 分析效能的實踐步驟以外，還有很多關於索引的基礎知識的文章。
通常我會鼓勵大家把資料庫當做你工具箱中的另一個工具，而不是什麼非學不可的惡魔。但我希望，以上的提示可以幫助初學者避免一些基本錯誤。
特別感謝 @mdeggies 和 @rdegges 最初的討論給了我靈感。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
