如何用Python構建MySQL數據處理系統

如何用Python構建MySQL數據處理系統，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

我是一名自然語言處理/機器學習科學家，而我不認為具有良好的計算機科學背景就能夠成功地在這個領域工作。我所認識的杰出研究人員可能由于某些原因而不具有熟練的技能，無法成為實時開發和存儲庫團隊的一部分。所以，我仍然想分享它們，也許有人會發現這些信息很有用。

我希望人們會喜歡我所講的故事。

（1）處理異常是至關重要的

當我第一次嘗試連接到存儲在谷歌云上的這個特定MySQL數據庫時，曾遇到許多不同的錯誤。當設置代理時，對很多代理進行了體驗。問題是，在代碼開發的第一階段，最好是處理所有的錯誤，特別是與連接有關的錯誤，如果需要的話，引發這些錯誤，否則調用Exchange語句。

這聽起來很簡單，但在我的例子中，可能有環境變量，其中有UNIX套接字名稱和節點環境名稱，它們的值可能不正確，數據庫憑據也可能不正確，我可以擁有它所有的東西。我在處理這些例子期間花費幾個小時，但節省了很多時間，我很高興將這段時間用于這個階段的項目開發。

（2）適當的抽象類是無價的

在處理抽象類時，你需要記住的最重要的事情是，可能需要花費大量時間和注意力來定義它，并且也確實需要它。我的存儲庫的結構基于這樣一個事實，即我必須創建許多.csv文件，這些文件具有非常相似的模式（唯一鍵）。事實上，我有很多類似的提取器、算法、數據后置處理器等工具，所有這些都被簡化為基本抽象類，這使得下一個模塊的創建更加容易。

當你編寫第n個模塊時，可以意識到你的類已經完成了，并且明白編譯過程中沒有定義的構造函數和一些方法已經實現了，因此不需要為它們煩惱。

（3）靈活的存儲庫結構總是最好的

有時它可能看起來有點難看（例如，在一個文件夾中有1個文件），但如果看到需要更改一些關鍵模塊（例如文本預處理器）并且這樣做，只需更改1-2個文件，那就很好了。

我并不是一名軟件架構師，所以很難說出這個領域的優點和錯誤，但我認為組件的高度碎片化和獨立性總是良好的。我自己開發的repoI有大量的小文件夾，并且引向它們比嘗試使整個架構更加容易（也許更漂亮）。

（4）數據科學模型的測試是值得的

我沒有足夠的時間來完成涵蓋所有案例的完美測試。我仍然提到這一點的原因是，如果你沒有那么明顯的ML/NLP模型行為，最好至少為了自己而進行測試。

我沒有很多NLP/ML算法（其中大部分算法都很簡單），但如果沒有實施哪怕最簡單的測試的話，它們的其他部分就無法支持。此外，在更好的模型理解方面，測試通常是有用的，這是因為通過斷言語句，當希望在頭腦中刷新算法時，一些算法概念可能變得更加清晰。

（5）使數據庫符合第三范式

有時這可能是人們討論的一部分，但是如果不使所有3個語句完全適用于數據庫，就無法編寫有效的數據處理系統。如果沒有它們，一些不明顯的查詢問題經常發生，甚至無法找到問題所在。

這里有一個簡短而簡單的SQL NF指南，我認為最好多看幾遍。（https://www.geeksforgeeks.org/database-normalization-normal-forms/）

（6）記錄錯誤

在實現記錄時，通常不會查看收到三年所有的警告和錯誤，但有些錯誤可能不可重復，而且日志記錄幫助理解發生了什么事。我是在我的本地機器上實施的，當服務器上的某些東西沒有工作時，通過查看類似的案例，可以節省幾個小時的時間。

（7）除非數據庫非常簡單，否則不需要對象關系映射（ORM）

在這個項目工作的很長一段時間里，我真的很擔心需要用對象關系映射（ORM）重寫所有內容。但是我錯了。

實際上，像SQLAlchemy和Peewee這樣的東西適合小型的簡單數據庫，但是它們不適合像復雜數據庫（有時它需要4個分組和5個連接來編寫一個查詢）。它們很優雅，有時非常簡單和美觀，但無論如何，如果你只使用連接器API，就不能擁有盡可能多的控制權。我決定使用MySQL Connector，因為用對象關系映射（ORM）編寫所有內容可能會使棘手的事情變得更加復雜。

結論

這個注釋與ML/ NLP算法解釋及其性能討論無關，但我仍然認為它很有用。我希望在開始研究這個項目之前已經知道了上面描述的所有陳述，但也確定，只有花費一些時間來修復bug，并尋找實際問題之后，它們中的一些問題才會變得清晰易懂。

關于如何用Python構建MySQL數據處理系統問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。