也有專業領域的圖表靠bi是做不到的，bi只解決了常見的圖表處理，專業領域的還是得靠寫程式碼，連圖表控制元件也用不了。

Bi在資料視覺化方面確實有很多應用，但在資料處理的速度與資料容量上，還不能完全替代sql，特別是各種程式語言也只有SQL介面而沒有bi介面，bi要走的路還很長，談替代尚早

正是在類似問題上的誤判、錯誤選擇，使我們喪失了許多機會，留下了無數的“死穴”。

這個問題，在軟體開發人眼裡根本不是問題，你之所以能夠“拖拽”出資料，是開發人員給你寫好了sql語句。

請你記住，不是你聰明，在這裡發現了“超車”的機會。是你父輩的努力，使你坐在了不該坐的位置。

把位置留給正確的人吧。

就像你說的，bi工具是可以拖拽來形成分析和報表的，確實很方便，現在也有很多美觀的圖表可以的。

但這只是形成分析或報表的最後一步，前面你需要根據分析的事實，去確定維度和指標，並形成事實表，特別是聚集型的事實表，從業務源資料彙總過來的話，一般都需要一定量的計算、換算和轉換，雖然也有etl工具可以輔助，但不能解決全部，還是需要自己寫sql編碼實現的。 特別是源資料量大的時候，按我的經驗，完全依靠etl去轉換，效率有時候真的很低。

另外，以上也僅僅是bi應用的情況。

還有很多業務場景不是bi模式的，更需要sql去處理資料庫資料了。這又是另外一個話題，不在這繼續探討了。

首先你說的東西有但是開發公司自己有沒有這樣的平臺，沒有需要買有的話開發一套人工維護和開發費用多少？而且開發出來或者用市場上的大多都是小眾化產品說白了就是會的人少那麼招工難，招到了花多少錢養？就算做好了bi的指標也不過就是SQL語句只不過用記憶體資料庫快取快速重新整理，其實付出這麼大成本還不如總SQL做而且會的人多整體成本低

我來說下不同觀點吧，如果上了bi報表，你想想，bi報表開發的工作由誰來做？！找技術人員吧，寫sql就行了，業務人員吧，工作量增加了很牴觸的。從人性的角度上，除非是業務人員本身就自發性的需要它會用它，否則都不如找開發人員搞合適！

這個問題問的我一臉懵逼啊。bi的資料都是利用sql加工後的資料來視覺化。就像一個人問我現在桌子上有香蓬蓬米飯，為何還要買個電飯鍋一樣

這是一個場景和職責問題，如果一個開發人員，那肯定寫sql除錯方便快，如果開發能力不是很強，任務簡單，自然是拖拽幾下出來最好，特別是業務人員如果自己想分析資料，學sql成本相對高