這篇文章討論了 SQL 的演變及其在當前技術領域中的作用。以下是文章的要點摘要：
2000 年代初，開發人員需要熟悉一系列技術，包括用於資料庫互動的 SQL。然而，隨著 IT 專業化的興起，出現了前端工程師、測試人員、資料科學家、DevOps 工程師和 SRE 等角色，每個角色都有自己的專業技能組合。
SQL 已有半個世紀的歷史，但它仍然是技術行業的一項重要技能。正如 TIOBE 指數所顯示的那樣，儘管各種程式語言層出不窮，但 SQL 的需求量仍然很大。
專家的崛起
隨著九十年代運營的興起，IT 行業的專業化程度也在不斷提高。我們已經有了一段時間的 DBA，但 "開發 "逐漸被前端工程師、測試人員、資料科學家、DevOps 工程師，以及後來的 SRE、安全工程師......所取代。
之所以說這是一個延續，是因為這個過程從計算機出現時就開始了，從最初的物理學家和技術人員開始，他們維護和程式設計的機器有房間那麼大，到 60 和 70 年代分化為 COBOL 和 FORTRAN 程式設計師，到 80 年代發展為系統管理員，然後是網路管理員，等等。
醫學界也有類似的情況。從前，我們有一位 "船上的外科醫生"，他必須處理幾乎所有你在拖著重炮迎戰敵人時可能會遇到的疾病，以及（在和平時期）患有疾病的水手分享他們從岸上帶來的任何疾病。幾百年後的今天，我們有了專門從事耳部手術的整形外科醫生（耳科醫生）。
計算機工作似乎也發生了類似的情況。從前，每個在工作中與計算機打交道的人都可能需要輸入（甚至編寫）幾個 SQL 查詢，而現在有了資料科學家。現在，開發人員會參加 Scrum 會議並抱怨 JIRA（甚至不怎麼寫 JQL）。
年輕人可能沒有學過 SQL
但他們往往精通 PromQL 和 GraphQL 等其他查詢語言。這表明，與過去相比，SQL 的普遍教授或要求可能會減少。
使用關聯式資料庫與使用 MongoDB 等 NoSQL 資料庫的爭論：
- 一些開發人員更喜歡 NoSQL 資料庫的靈活性，
- 但是關聯式資料庫和 SQL 所提供的結構對於有效管理和查詢資料至關重要。
結構和資料管理：
資料庫表結構也存在過於僵化的觀念：
- 人們認為結構 "難以更改"，但這隻有在有許多使用者和程式碼依賴於資料庫或有大量資料的情況下才會發生，而不是在最初建立系統時。
- 更改資料庫可能會很麻煩，因為不同廠商的語法各不相同，你經常需要查詢是 ALTER TABLE ADD INDEX 還是 CREATE INDEX。
這其實是瀑布程式設計與敏捷的區別，事先規劃設計好前提條件，然後跳進坑裡面去，其實不假設任何前提或約束反而是更敏捷，至少不會自己束縛自己。
這種區別非常類似“分離關注”，是在不瞭解問題全面情況下就能將關注分離嗎？在不瞭解敵人有多少人的情況下，你就將自己計程車兵分離成一股股小部隊嗎？送人頭嗎？
資料庫結構設計是你在你認為全面瞭解了問題的情況下設計的，但是啪啪打臉是經常發生。
當然，結構對於控制資料和啟用強大的查詢是必要的。
使用 LLM（大型語言模型）來協助 SQL 查詢編寫，人工智慧可以幫助完成資料庫管理任務。
現實重點
當前，與資料相關的任務（包括程式設計和管理）通常被歸咎於資料科學家，而不是被視為一般計算工作的組成部分。
雖然 SQL 的需求可能不那麼普遍，但它仍然是資料操作和分析的一個有價值的工具。