SQL 反模式
所謂專家就是在一個很小的領域把所有錯誤都犯過的人。
邏輯數據庫反模式
1.存儲多值屬性。
反模式：格式化的逗號分隔列表。增加插入，更新，刪除復雜性，無法利用索引，通過逗號列表中的某一屬性查詢效率低，無法驗證列表有效性，需要選擇合適的分隔符，長度限制。
合理使用：在不需要獲取單獨項，僅展示列表時可以提高效率。
解決方案：創建交叉表：id1，id2。
2.分層存儲和查詢。
反模式：總依賴父節點。parentid。
合理使用：鄰接表優勢在于能快速定位直接父節點，容易插入新節點。通過WITH表達式也可以很好的遞歸。
解決方案：路徑枚舉、嵌套集、閉包表。
設計???表??查詢子節點?????查詢樹???插入???刪除????引用完整性
鄰接表??1???????簡單????????困難????簡單????簡單??????是
遞歸查詢?1??????簡單?????????簡單????簡單????簡單??????是
路徑枚舉??1???????簡單???????簡單????簡單????簡單??????否
嵌套集??1???????困難?????????簡單?????困難?????困難??????否
閉包表???2???????簡單?????????簡單????簡單????簡單??????是
??
3.建立主鍵規范。
反模式：主鍵名叫id，并自動增長。冗余的鍵值，允許重復項，意義不明確，無法使用using關鍵字。
合理使用：框架原因需要id，或者自然鍵太長，長字符串索引開銷較大。
解決方案：擁抱自然鍵和組合鍵
4.簡化數據庫架構。
反模式：無視約束，不添加約束。
解決方案：聲明約束，唯一性，外鍵，檢查等。可支持級聯刪除和更新。外鍵需要一些系統開銷，但對于其他的方案，外鍵更高效：
不需要在更新和刪除前執行select
在同步修改時不需要鎖住整張表
不再需要定期監控孤立數據
5.支持可變屬性。
6.引用多個父表。
反模式：使用雙用途外鍵。即通過某個字段判斷另以字段要關聯的表。
合理使用：當程序框架中可以很好支持多態關聯，并封裝了風險，可以選擇使用。
解決方案：
創建交叉表：
A id....
X1 id
X2
若要保證唯一性，可增加unique約束。
可雙向查找。
?
創建公用超級表：
A : id
A1:id FK 。。。。。
A2:id FK 。。。。。
B：id，aid FK。。。。。。
查詢時
SELECT FROM b left join A1 using (ID)
left join A2 using (ID)
WHERE......
合并跑到：
通過UNION
7.存儲多值屬性。
反模式：創建多個列。x1,x2,x3。
查詢需搜索多列，添加刪除更新不安全性，無法知道更新哪一列，可能某列沒有值，無法保證唯一性，可能列不夠用要增加列。
合理使用：當屬性列固定，當屬性列互相沒有關系，相互獨立。
解決方案：創建從屬表
8.支持可擴展性。
反模式：克隆表、克隆列。
將將很長的表拆分成多張小表、將一個列拆分成多個子列。
不斷產生新表，數據完整性，同步數據，確保唯一性，跨表查詢，同步元數據，管理引用完整性，標識元數據分裂列。
解決方案：水平分區、垂直分區，使用關聯表。
水平分區：物理拆分。
垂直分區：根據列拆分。
物理反模式
9.取整錯誤。
反模式：使用float類型。會舍入，不精確。
合理使用：當取值范圍大于interger和numeric時就要使用float。
解決方案：使用numeric和decimal。盡量不要使用浮點數。
10.限定列的有效值。
反模式：在列定義上指定可選值。用check約束。
無法知道有哪些可選值。添加新值困難，無法刪除老值，可移植性低下。
合理使用：候選值幾乎不變時使用，可在代碼中維護列表。
解決方案：在數據中指定值。創建一張表。
11.存儲圖片和大媒體。
反模式：假設你必須使用文件系統。文件不支持delete，不支持事務隔離，不支持回滾，不支持數據庫備份，不支持sql訪問權限。
合理使用：存在文件系統的好處：
數據庫空間占用小，不包含文件的備份快，預覽編輯圖片方便。
解決方案：在需要時使用blob類型。
12.優化性能。
反模式：無規劃的使用索引。不使用索引，索引不足；使用太多索引和無效索引；執行一些無法使用索引的查詢。
解決方案：測量，解釋，挑選，測試，優化，重建。
查詢反模式：
13.辨別懸空值。
反模式：將NULL作為普通值。
解決方案：將NULL視為特殊值。
14.獲取每組最大值。
反模式：引用非分組列。
解決方案：無歧義的使用列。
15.獲取樣本記錄。
反模式：隨機排序。使用rand（）表示整個過程無法利用索引。
合理使用：數據量較小，不會有性能問題時。
解決方案：沒有具體的順序。
專用方案：sql server：使用table-sample子句。
oracle 使用sample子句。
16.全文搜索。
反模式：模式匹配。like %a%?或正則表達式。無法從傳統索引上受益。返回預料之外的結果。
合理使用：一些查詢很少執行，不需要優化。
解決方案：使用正確的工具。
使用特殊的搜索引擎技術而不是sql，即數據庫擴展的全文搜索。。講結果保存起來以減少重復的搜索開銷。
17.減少SQL查詢數量。
反模式：使用一步操作解決復雜問題。
解決方案：分而治之。一步一個腳印，將復雜查詢拆分，尋找union標記，通過代碼生成sql語句如
SELECT 'UPDATE X SET X = ' u.id FROM u
18.減少輸入。
反模式：捷徑會讓你迷失方向。破壞代碼重構，使用通配符*增加開銷，
解決方案：明確列出列名
應用開發反模式：
19.恢復或重置密碼。
反模式：明文密碼。
解決方案：先哈希 后存儲。給哈希加料。重置密碼而非返回密碼。
20.編寫SQL動態查詢。
反模式：將未經驗證的輸入作為代碼執行。
解決方案：不信任任何人。過濾輸入內容，參數化動態內容，給輸入的值加引號，將用戶與代碼隔離，找可靠的人幫你審查代碼。
21.整理數據。
反模式：填充角落。看到分配的編號不連續，第一反應是填補其中的空缺。
解決方案：克服心理障礙。用rownumber定義行號，使用guid。
向對方解釋行號不連續的原因，清楚的表明開銷，使用自然鍵。
22.寫更少的代碼。
反模式：無米之炊。忽略了數據庫的返回值，和程序代碼混在一起閱讀sql代碼。
解決方案：關注返回值，查看程序生成的sql代碼。
23.采用最佳實踐。
反模式：將sql視為二等公民。
解決方案：建立一個質量至上的文化。
清晰的定義項目需求，并寫成文檔。設計并實現一個解決方案來滿足需求。驗證并測試解決方案是否符合需求。
數據庫文檔：
實體關系圖。表、列視圖。關系。觸發器。存儲過程。SQL安全。數據庫基礎設施。ORM。
24.簡化MVC模型。
反模式：模型僅僅是活動記錄。
解決方案：模型包含活動記錄。
總結
- 上一篇： 活动图与流程图的区别
- 下一篇： 完整SQL分页存储过程（支持多表联接）