※ 引述《ripple0129 (perry tsai)》之銘言：
: 通靈一下
: 問題是不是報表類啊
: 要全表或大量join大量計算的
: 資料少跑一下SQL就好
: 資料大跑到炸掉
: 會去想到資料大時會炸鍋
: 表示有經驗了啊
: 多的是新手沒想過這種問題
: 不過不要緊了
: 等慢到一定程度
: 就會開始跑daily的過去統計
: 到時重構就好
: 先求功能出來且正常
: 未來再處理效能
: 沒有足夠filter條件的SQL
: 往往都是要重構的
: 別擔心遇到了處理就好
: 只要確定目前儲存的資料
: 未來有辦法做重構即可
: 如果現在設計的schema不符合未來重構
: 那就要換schema來儲存
以前遇過是客戶要的報表有可預料的效能問題(不要在數據庫對海量數據
進行recursive string concat). 但經理已經答應了客戶.
當時的做法是:
1) 要經理向客戶解釋情況, 最好說股客戶不要會出問題的部份. 不過這被經理否決了
2) 讓經理另外找人做, 別說我故意做差這功能.
結果代我做這報表的同事寫出來的東西, 即使在demo data量下也要跑十多分鐘
才能顯示.
後來我用我的方式重做, 也不過是把時間壓到一分鐘左右. 但留意這是在demo data
的環境下. 實際使用的話一年半載後不把那部份去後誰也別想救. 經理沒辦法下
也只能用我寫的去交差了.
當然, 一年半載後我已經離職了, 也沒看到後續如何.
重點是: 沒實作相應環境證明你說的情況, 上司不見得會聽進去.
Clone一個環境, dummy fill一堆數據把量撐大, 讓上司實際看情況比較重要.
而更重要的是過程要loud, 要確定相關人物都知道你已經事先警告過了,
也花時間實業證明了, 這也要繼續的話, 日後出問題就和你沒關係了.