剛做開發人員的時候，需要掌握的東西非常多。首先是程式語言本身，還有所有你用到的框架的的特定用法，之後(也可能是之前)，前端開發的東西也會混進來，在開發過程中你還要考慮資料存在哪的問題。
起初，由於你有太多東西需要迅速掌握，在應用設計的過程中，會傾向於把資料庫放在後面考慮(大概因為它對使用者的使用體驗沒什麼影響)。結果就是在處理資料庫的時候，會發現很多不好的實踐。這裡舉幾個例子。
1. storing images 儲存
資料庫裡不應該放。你可以做的事情並不代表你就應該去做。會占用資料庫裡相當大的空間，吃掉不必要的 io 資源從而拖慢應用。這個錯誤最常出現的情況，就是新人將用 base64 編碼，然後將其儲存在很大的 text/blob 字段當中。
更好的辦法是直接將上傳至像 amazon s3 這樣的雲服務上，然後用資料庫裡用 text 字段儲存的 url。每次要載入一張的時候，只要把的 url 輸出到有效的
2. limit/offset
分頁在很多應用中都非常常見。從你開始學習 sql，(你就該知道)最直接的分頁方法就是先用 order by 對資料庫的一些列進行排序，然後 limit 返回的結果數，對除第一頁外的每一頁使用 offset。這看起來很符合邏輯，直到你處理中等規模應用時才意識到：
它對資料庫施加的負載是非常痛苦的。
它具有不確定性，記錄應該隨著使用者翻頁而改變。
不幸的是：分頁非常複雜，目前還沒有乙個萬全之策。
3. 用整數做 primary key
(uuid)還有其它的好處，那就是它不會無形中暴露給使用者(資料庫中)有多少使用者、列表、或是這些 key 所指代的任何東西。
4. 新列中的預設值
無論你做這個工作有多久，都不會一次就建立出乙個完美的 schema。最好是將資料庫 schema 視為乙個持續演化的文件。不幸的是：向資料庫中新增一列是件很容易的事，這也就意味著在新增列的時候把工作搞砸同樣很容易。預設情況下，如果你新新增了一列，通常是允許有 null 值的。這個操作速度很快，但大多數應用實際上不太想讓他們的資料裡有 null 值，他們會想要設定預設值。
如果你在表裡新增設定了預設值的新列，會對這張表觸發一次完全的重寫。注意：這對應用中的任何(資料量)很大的表都非常不利。(正確的方法)恰恰相反，最好是先允許 null 值存在，這樣操作就是即時的，接下來再設定預設值，再用後台程序去回溯更新資料。
5. 過度標準化
開始學習資料庫的標準化的時候，(標準化)感覺就像是很正確的事。你建立了乙個 posts 的表，裡面包含 authors，每篇文章(post)都屬於乙個條目(category)，所以你又建立了乙個 categories 的表，然後再建立乙個把它們倆 join 在一起的表，post_categories。從根本上來說，這樣做標準化也沒什麼原則上的錯誤，但是某種程度上，標準化的收益正在遞減。
在上述例項中，categories 可以簡單地作為 post 裡的乙個 varchar 字段。標準化是件很有意義的工作，但是每次處理包含多對多關係的表時都要深思熟慮，想想你是不是真的需要在關係的兩邊都各用乙個單獨的表。
修正：值得一提的是，欠標準化也是個問題。這裡並不存在「一刀切」的解決方案。有時完全不做標準化和完全標準化也行得通。像 @fuzzychef 說的那樣：「適度標準化，即金髮姑娘原則(the goldilocks principle，意為適度的是最好的)」。
總結
通常我會鼓勵大家把資料庫當做你工具箱中的另乙個工具，而不是什麼非學不可的惡魔。但我希望，以上的提示可以幫助初學者避免一些基本錯誤。
新手程式設計師常犯的十個錯誤
先介紹下背景，博主由運營轉行前端，入職乙個月，完成了乙個相對較大的模組。由於基礎相對薄弱，犯下了不少錯誤，故想記錄下來警醒自己和分享各位。前端技術棧是es6 backbone react antdui,後端使用的ruby on rails。mvc說起來非常簡單易懂，即model view contr...
新手程式設計師常犯的幾個錯誤
優效學院，名師執教，學習更優效，it 四六零五七零八二四 缺少必要的注釋 大段的if else 缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在 hack 或複雜邏輯的 缺少注釋會讓後來者不明所以。為了你好，也為了後來者好，請務必加上 說不准以後還是由你來維護這段 不變和變化的部分拆分 程式設計...
設計新手在PS中最常犯的6個錯誤
photoshop是最流行的影象合成軟體，粉絲遍布全球，不過對於新手設計師，可能犯一些常見的錯誤，在這篇文章中我列出了6個頻率較高的錯誤，來看看你躺槍了木有。一 少圖層，沒分組 多創造圖層，學會給圖層分組是乙個專業設計師必須學會的，這不僅有利於你的修改，也是團隊合作中少不得的習慣。在剛開始的設計中，...