在年輕的資料從業者中，越來越多的人認為SQL不是“很酷”，不夠好甚至更糟，認為“ SQL不夠專業，真正的資料科學家應該編寫程式碼”。然而，自己的經驗卻使我對此反感。無論是在資料收集和清理等管道的最初階段，還是功能工程和報告生成的後期階段，我都開始欣賞SQL的強大功能和多功能性以及RDBMS的有效性。

實際上，不僅吸引我的是SQL和RDBMS的工具性質，而且吸引和涵蓋了它們的整個“ SQL傳統”。自從Codd在70年代引入關係模型以來，實用主義的水平就建立並推動了資料管理。

在本文中，我收集了有關SQL主題及其如何適合現代資料實踐的一些想法。上週我在一次演講中遇到了一波難以置信的動機，當時我聲稱現代資料專案可以通過儘早採用SQL並堅持使用SQL來極大地受益：“從SQLite開始，以Postgres擴充套件”的理念。

再使規範化規範

現代NoSQL系統的無規範結構本質實際上消除了對具有深思熟慮的資料模型設計的需求。您可以將資料轉儲到靈活的“文件”“集合”中，而不是更嚴格的“行”“表”中，然後使用功能強大的查詢語言來提取所需的內容。為什麼要這樣做？因為您可能無法預料以後需求將如何變化，所以在RDBMS中更改架構可能會很棘手。聽起來很公平。理論上肯定是這樣。

但是，我與現有NoSQL部署的合作越多，我越相信它們的無結構本質已成為藉口和不願事先停留在專案資料模型上的藉口。

我看到太多的應用程式從零時開始就依賴MongoDB作為其主資料庫來處理“普通的”事務資料。然後逐漸地，他們最終不得不“轉換特定集合的欄位”，“建立充當錨點的中間集合”，或者更糟糕的是通過cronjob進行轉換而提供“其NoSQL資料庫之上的表格層”的除錯專案。

將資料以表格格式匯入關聯式資料庫，甚至引入“每個人都應該使用的Python庫，以便以表格格式獲取資料，因為這就是Scikit-Learn所期望的”。

如今，大多數主要的RDBMS確實提供了某種無結構的支援，通常使用具有豐富查詢語義的JSON資料型別。

這種方法的好處是，可以在不犧牲ACID一致性的情況下為它們的結構化和非結構化資料提供一個資料庫。既可以在引用級別（即外來鍵）確保資料完整性，又可以通過約束，索引和觸發器來嚴格管理資料質量。

使ETL更接近資料

ETL是現代資料驅動型工作的資金消耗機器，並且是每個資料科學家日常生活中必不可少的惡魔。然而，這可能是資料管道中不那麼周全的想法。無數機器學習工程師帶著使用隨機森林和支援向量的希望開始了他們的模型選擇工作，直到後來才意識到沒有足夠的乾淨資料可用，他們不得不使用簡單的迴歸。

我認為，如果將更多的資料清理過程推到資料庫級別，則資料管道將更加平滑和整潔。

讓我們關注關聯式資料庫的另一個典型特徵：觸發器和儲存過程。它們都可以成為資料清理和轉換工具箱中的重要工具。

由於必須在固有的宣告性環境中編寫過程程式碼，因此資料庫伺服器程式設計以前很難適應。但是今天，情況有了很大的改善：語法變得更加甜美，甚至可以使用過程語言來編寫其觸發器和儲存過程函式。使用Postgres，甚至可以在資料庫中編寫Python和Perl程式碼！

SQL功能強大

我的經驗表明，我在查詢級別建立的功能越多，在嘗試使用不同的功能向量時就具有更大的靈活性，並且模型選擇和評估越快。編寫查詢時，資料庫將成為畫布，您可以在其上繪製漂亮的模型。無需在磁碟和記憶體之間跳來跳去，也不需要在資料庫和熊貓之間跳來跳去。您可以自由組合來自不同表的資料，在各個列之間執行簡單或複雜的操作，並讓查詢優化器為確定為您建立資料集的最佳方式進行繁重的工作！

SQL和關聯式資料庫已經走了很長一段路，如今，它提供了資料科學家可以要求的幾乎所有功能。Postgres（甚至包括SQLite和其他主要的關聯式資料庫）提供了一些文字處理功能和自由文字搜尋功能，這些功能足以滿足大多數應用程式的需求。這是否消除了對NLTK或ElasticSearch的需求？絕對不。

但是，在利用SQL方面有一些警告。首先，由於其宣告性，SQL幾乎總是會為您提供結果，但它們可能並不是您所要的。SQL要求細緻和謹慎，因為除錯非常困難。您無法列印“我在”以檢查是否存在錯誤的迴圈條件，等等。實際上，您只能進行的除錯是檢查執行計劃並對其進行反向工程。

在另一個“文化”方面，我注意到的一件事是，諸如“乾淨程式碼”和“可維護性”之類的最佳實踐和概念在SQL世界中並不那麼普遍。我可以將其歸因於許多方面，但我只是強調一個事實，即太多“商人”使用SQL。他們將其視為“獲取資料的臨時工具”，這種方法是正確且務實的，但是我們應該嘗試引導他們將SQL用作程式碼庫，該程式碼庫將被其他人使用，並應被用作實現以下目的的工具：與資料庫和其他程式設計師進行通訊。

關聯式資料庫具有成本效益

關聯式資料庫通常在財務上也更有意義。像MongoDB和ElasticSearch這樣的分散式系統非常耗錢，可能會浪費您的技術和人力資源預算；除非您絕對確定並已經計算了數字，並認為它們確實對您的情況有意義。

以上只是挑選摘錄，詳細點選標題見原文。