materoalized view 物化視圖 作爲非規範化設計的一種手段,
首先，應學會充分利用簡單、傳統的技術。
只有完全掌握了這些技術，才能正確評價它們的侷限性，最終發現它相當於新技術的潛在優勢
1 總結：先打基礎，再趕時髦：擺弄新工具之前，先把手藝學好
臨時表的索引（如果有的話）可能不是最優的，因此，查詢臨時表的
語句效率比永久表的差
：暫時工作表意味着以不太合理的方式存儲更多信息。
將一次“大批量數據的處理”分割成多次“小塊處理”是個壞主意，除非對數據庫的修改太昂貴，
否則不要使用，因爲這種方法極其低效
幾千個語句，藉助遊標（cursor）不斷循環，很慢。換成幾個語句，處理同樣的數據，
還是較慢。換成一個語句，解決上述問題，最好。
避免:
過程邏輯（procedural logic）”
優化器（cost-based optimizer，CBO）
然而，過程邏輯及其之後的處理相同數據的語句，可以編寫到一
個單獨的SQL 語句中，CBO 就是這麼做的，從而獲得最高效的執行方式。
總結：在合理範圍內，利用每次數據庫訪問完成儘量多的工作。
如要使用函數，始終應首選DBMS自帶的函數。這不僅僅是爲了避免無謂的重複勞動，還因爲
自帶函數在執行時比任何第三方開發的代碼更接近數據庫核心，相應地其效率也會高出許多。
總之，統計記錄數極可能意味着重複全部搜索，因爲它對相同數據處理了兩次
總結：沒必要編程實現那些數據庫隱含實現的功
SQL不需要循環能力，因爲它
本質上是在操作集合，SQL只需要執行條件邏輯的能力
總結：有可能的話，用一個語句處理多個更新；儘量減少對同一個表的重複訪問。
可以僅對代碼中非共用的表（本例中即E1和
E2）使用union，然後配合篩選條件，把union 語句降級爲內嵌視圖。
你可以過濾分了組的字段，也可以過濾聚合（aggregate）結果（例如檢查count() 的結果
是否小於某閾值），或者同時過濾兩者；SQL 允許在having 子句中使用這類條件，但應該在
group by 完成後才進行過濾（比如排序之後再進行聚合操作）
總結：儘早過濾掉不需要的數據
總結：當查詢的結果集很大時，索引未必必要。