為什麼我不贊成開發來寫檢視

    我有個“歧視”，就是開發寫的檢視基本都是有問題的。這來自於我多年的實際工作。檢視是資料庫的一個工具，但是絕大部分開發不是從資料庫角度出發來寫的。所以一般來說寫的並不會讓資料庫很舒服，甚至是痛苦。

    今天有一個開發拿SQL找到我，我一眼看到一個V_XXX。不用問，這就是一個檢視，我對開發說你開啟它，我看看。我極度懷疑這個寫的不合格。開啟一看，果然沒讓我失望。寫的異常複雜就不說了，都這樣。我們今天說點與眾不同的。就是結尾的地方我眼前一亮看到group by 列1，列2，列3.。。。。。。我就往下看，很多。多的超過我見過的記錄了。我饒有興致的數了一下134個。也就是說前面多複雜我先不管，最後group by 了130多列。好傢伙，我從業十多年著實沒見過這樣的。

    group by是分組，130多個欄位組合的分組我也是生平第一次見。這種分組排序消耗是很大的，其實就是嚴重的設計問題。我建議是重新梳理需求，我們重寫查詢，選擇合適的基表來完成。不要在這個上面繼續錯下去了。

    我想起我第二家公司時候看到一個之前的人寫了4000多行的儲存過程，為的就是為了給表定時增加一個分割槽。可憐的人，不知道資料庫有自動分割槽的功能。一句話就搞定了。每次想到這個時候我就想到，TiDB是沒有儲存過程、觸發器和函式的。可能即使是國產第一的資料庫考慮到如果讓開發自己DIY的話，對資料庫的衝擊太大。還是別給他們這種自由了。

   我一般寫檢視和儲存過程這種，基本10行解決。10行解決不了，要麼需求問題，要麼設計問題（表設計或者邏輯設計）。

   有的時候真的佩服資料庫，這種“垃圾”SQL居然也執行下來沒有奔潰，資料庫也真不容易。而且還執行了10年以上了，當然換一種資料庫是不是還是能支援，還真不一定。大機率可能會奔潰。畢竟不是每個資料庫都這麼慣著的。

   想起一句耳熟能詳的話：在糟糕的設計下，一切最佳化都是無能為力的。（也許強大的硬體，比如一體機那種能解決）。所以設計（表、檢視）是至關重要的，需要有專業的人士來完成。