1樓：北斗核潛艇
是的，廣東某些智障廠的管理也是想省一筆錢異想天開的直接excel運算元據記錄，然後內部管理結構和財務流程就跟吃了農村那種打鳥的銃彈一樣，財務倉務人事喜迎工廠倒閉
2樓：姜健
老婆PM，我DBA，不是我不教，是她太懶....
另外，從乙個DBA的角度講，測試環境還好，生產環境讓乙個PM直接去查，哪怕沒有任何寫許可權，哪天乙個select寫得太爛影響了現網服務腫麼辦，太不放心了.....
3樓：hanna
這裡是資料探勘學生一枚，不知道資料庫是個什麼存在，表示並不知道資料庫也能做資料分析，然而此資料分析跟資料探勘是一回事麼，學渣表示貴圈很亂呀
4樓：劉不忙
做為中層管理者，excel是做報表用的，SQL是在資料庫中驗證資料準確性用的。有必要學習一下。
用人肉介面，你不怕他出錯？
5樓：Edward
我覺得產品經理不用管這些，好的產品經理應該完全從使用者角度去想，好玩好用有意思，產品經理拘泥於技術，我讓產品設計產生侷限性
6樓：言子期
spatch?uri=/book/26798544/
spatch?uri=/book/26333068/
spatch?uri=/book/26792425/
7樓：李超群
學會使用Excel中的資料連線功能，你會發現有一扇新世界的大門開啟了。
使用ODBC連線Mysql資料庫，加上查詢語句，高階一點再加上一點簡單的VBA操作，其實是可以在Excel中實現乙個自己可定製的簡易BI平台的。
我自己有大量的工作都是通過掛排程指令碼，扔到Hadoop集群中計算好，結果導到Mysql資料庫中再通過Excel資料重新整理展示，極易方便。
8樓：劉鑫
做這些事情，我大概也有快十六年了吧……關係型資料庫做資料分析麼，當然有它專業的方面，人家原本設計就有這個方向，特別是商業的MSSQL/Oracle這些，OLAP都是有專門的工具支援。但是這套體系比較尷尬的是有用沒用總得掛著哪些Service，而且單就資料分析的程式設計來說，其實並不會比 Pandas 或者 R 這類東西更方便更好管理。特別是在單機作為桌面工具使用，不是很經濟。
現在不是2023年前後那十年了。可以選擇的很多。小規模的桌面使用，Pandas 之類的工具就很好。
辦公室級別的，或者企業高實時性專案需求，關係型資料庫是經典的解決方案。再大型的，新一代的分布式資料分析工具更有針對性。你這種情況，我推薦學一下Python，用Python的工具集（Pandas＋Jupyter什麼的）去做資料分析。
9樓：leo rong
我覺得。資料庫要懂。要會操作。
乙個是對資料結構的理解，有利於對產品的設計。第二是你對資料的分析能力，可以幫助你對資料越來越敏感。第3我覺得，和程式設計師溝通可以更深入。
或者你可以不用自己操作，但是需要有資料獲取的思維和敏感度。在允許的時間內，獲取一種有用的知識，何樂而不為？
10樓：事業接班人
---這個位子本來放了乙個妹子，但是他們說tm是色情，老子妥協了。------
產品經理不需要學習怎麼去折騰資料。
記住，你只需要乙個玩xls的妹子，告訴她，你要什麼資料，
就可以了。
然後幹好你產品經理該幹的。
11樓：大能貓
題主提到的資料庫都可以匯出Excel來進行統計，但是在資料庫較大的情況下便不適合了。目前國內的程式設計師水平差距很大，雖然面試的時候都會說把需求擺在第一位，但是相信大多數人都對專案結束後的很多莫名其妙的問題而無可奈何。
本人是從事資料分析的職業的，雖然水平很低，但是遇到過不少IT同事的奇妙思路。所以後來便自己從新拿起書本用sql。
資料質量，對於工作面向是最底層資料的工作者來說，說白了就是更多的型別描述和更大的資料量。這個時候Excel的劣勢就出現了，難以處理較大量的資料，儲存麻煩，大量資料下去重複都是個難題。這是邁不過去的坎，近些年市場上對於SAS和SQL的人才需求量大增也是有這樣的關係，大多數公司就算招到了高階技術人才也不一定會順利建模，但是基礎資料會越來越順。
對於一般不涉及開發和建模的人員來說，學會一般的增刪改查更新去重就可以了。
另補充一句，其實隨著學習的加深會發現不一樣的東西來促進工作的進步，這個道理可以應用在各個職業技能裡。
12樓：伊勢丹-買買提
學習excel的操作基本就夠了，這是產品經理的職業工具。
然後跟乙個資料庫玩的溜的程式設計師搞好關係就可以了
這是正確的套路，自己學資料庫，價效比實在太低，而且程式設計師很難相處麼
13樓：裝鱉
我不認為需要為了資料分析而學習資料庫。
我自學過資料庫，一些結構和簡單的增刪改查。
目的是為了加強理解方便和程式設計師溝通，以及自己將來創業備用。
我也曾嘗試學習資料探勘，但在學習的過程中發現這東西和想象的不一樣，偏技術，且用途好像沒有想象中那麼廣泛有價值。
在我看來產品經理能把谷歌統計研究研究就已經不錯了。包括谷歌統計的每乙個資料設定的原理，以及為什麼這麼設計都弄明白，就夠了，這不是件容易的事情。我當時研究谷歌統計的時候發現其他人知道的太少，很多現象我自己無法解釋，問別人也沒人明白，好多問題我到現在都不明白。
對資料和業務之間的關聯進行研究的價值比研究個是個程式設計師就能查詢的資料庫價值大太多了。
至於你想要的資料，你應該提要求給開發，讓他做功能匯出excel就好，excel的查詢和呈現結果的水平不會比你自己查詢要差。如果你發現excel無法滿足，說明你們應該開發出這樣的功能。因為無論是從安全的角度還是從流程的角度來說，產品經理是不應該直接接觸資料庫的。
資料庫是很重要的地方，產品經理這種三腳貓的水平還是遠離資料庫比較好。你可能說可以設定許可權等等，但即使從職業發展的角度上來看，我也不推薦幹這種費力且替代性強的事情。你的價值不會因為你能流暢的使用SQL語句查詢資料庫而增加。
SAP 新產品記憶體資料庫 HANA 的前景如何？
阿哲 適合sap生態圈，因為sap的應用一向就是S low A nd P ainful 用Hana解救一下挺好。不在這條線上的，慎重選擇，因為sap的東西黏性極強，一旦上了賊船就不要想下來了。要選擇快速處理海量資料，很多選擇，結合自己業務特點綜合考慮，不一定非要燒記憶體資料庫這條。 王永上 HANA...
學習資料庫有什麼經典書籍？
程式設計師程式設計指南 資料庫系統實現 第二版 提取碼 6oi6資料庫系統概念 提取碼 7bt0 資料庫系統概念中文第6版 提取碼 kqe0深入淺出MySQL 資料庫開發 優化與管理維護 第2版 唐漢明 提取碼 70uf 高效能MySQL 第3版 提取碼 pofh分布式資料庫系統原理.第3版 提取碼...
如何避免資料庫不響應導致資料庫執行緒池和業務執行緒池全部掛起？
資料庫讀寫執行緒做超時，哪怕非同步了，堵住了沒有超時一樣會死。再用個守護執行緒去檢測這些排隊的情況，一旦超出閾值就報警吧。在一般業務併發處理中，能丟擲主業務就丟擲主業務，讓主業務能最大併發處理。當然如果在主業務中資料庫響應很慢，而且持續時間很長，那麼無論執行緒池中多少個執行緒 執行緒無線多也不是什麼...