SQL反模式：SQL 建模與使用指南

來自專欄 資料庫開發者

上周末花了幾個小時刷完《SQL反模式》這本書，書里介紹了資料庫應用開發者最長遇到的一些問題，雖然這本書面向的讀者是使用資料庫的應用開發者，但它對資料庫管理員、資料庫開發者同樣會有啟發，強烈推薦閱讀。本書涉及的問題包括但不限於

1. 如何存儲多值屬性？
2. 如何使用關係模型表達樹結構？
3. 如何建立主鍵規範？
4. 如何支持可變的屬性/欄位？
5. 如何從表中隨機選擇一行？
6. 如何實現文本查詢的需求？
7. 如何存儲文件類型數據？
8. 如何限定列的有效值？
9. 如何表達精準浮點數？ 10.如何寫出安全（難以 SQL 注入）的 SQL 語句？
10. ...

針對上面的問題在實際的開發場景中都經常遇到，作者介紹了一系列「反模式」的設計思路，我發現很多都是開發過程中很容易犯的錯誤。以「如何存儲多值屬性」為例，最直觀的反模式設計思路就是「復用原來欄位，格式化的逗號分割列表」，如果需求比較局限，聯繫人數量不會無限制擴展，針對聯繫人欄位也不會經常有查詢、聚合需求，這種方法的確成本很低。

但實際上這種方法缺點很多，比如（1）針對這個欄位的查詢，基本都得使用正則表達式，而正則表達式沒有確定的規範，不同的資料庫支持都不一樣，導致寫出的 SQL 也不具備通用性。(2) 針對該欄位里屬性的查詢無法使用索引 （3）列長度有限制，屬性數量擴展有上限 ... 而這些隨著應用需求的不斷變化，可能對系統產生非常大的影響，擴展起來非常麻煩。

從資料庫開發者的角度看，對於這麼多可能誤用的場景，我們需要思考資料庫服務本身能做什麼工作來簡化、或者規避問題，比如

1. 很多新的存儲引擎都具備了 SAMPLE 隨機取樣的能力，方便用戶隨機獲取記錄，避免了用戶
2. 阿里雲資料庫上，專門有針對防 SQL 防注入的檢查，減小了用戶犯錯造成的影響
3. 對於屬性可擴展的需求，SQL 可能並不是最佳需求，一些基於 KV、Document 的介面的資料庫，如 Redis、MongoDB，可能是更加的選擇。
4. 對於文件存儲的需求，存儲在資料庫節點同機器上文件系統上有很多問題, 但量大的時候，存儲在資料庫里也無法滿足需求；目前比較常用的方案時，文件存儲到專門的分散式文件系統里，資料庫里存儲對象的標識名。

推薦閱讀：