什麼是SQL

自己原文公眾號： https://mp.weixin.qq.com/s/lZo9kgkjEY5qyUuRB0Z6rQ

當今開發語言用的最多的是什麼？（PHP是最好的語言）java和Python等等還沒說話。其實這些都是開發語言。我記得我有一次培訓，問在座的不連線資料庫的請舉手。幾乎都舉手了。說明脫離資料庫的開發幾乎不存在。幾乎不是說100%。前端就不需要連線資料庫。

    如果說連線資料庫那麼其實就不管你是VC++還是java或者Python。資料庫統統不認，資料庫提供的是ODBC、JDBC等等封裝好的東西，你只管用就行。所以說碼農才有了這種，就是做增刪改查。而做這幾個動作只能透過SQL（因為透過其他的資料庫不認）。這裡要說的redis 的put、mongo的insert、hbase的put、neo4j的match這些也是他們自己的SQL（雖然不是結構化查詢語言了，因為是半結構化資料，不能叫S了，但是這裡主要是表達一個意思）

   1970年，在加利福尼亞IBM的聖約瑟研究實驗室工作的年輕程式設計師codd，提出了根據不同資料之間的能夠辨別的關係來組織資料的概念。資料將被組織在二維表（行和列）中，一個表中的特殊專案可以與另一個表中的資料產生關係。codd看到了需要減少或除去資料中的冗餘，並且要允許資料透過邏輯而不是物理辨別來進行存取。codd關鍵的想法是透過適當資料的表對資料加以組織，也就是標準化的處理過程。

   下面是引用：

   1974年E.F.codd提出了全關係系統的十二條基本準則，只有遵循這些準則的系統才是全關係系統。以此可作為評價或購買關係產品的標準。

準則0：一個RDBMS必須能完全透過自身的關係能力來管理資料庫。這意味著，一個自稱為關係型的DBMS必須能在關係這個級別支援資料庫的插入、修改和刪除。準則0是下面十二條準則的基礎。不滿足準則0的DBMS都不是RDBMS。

準則1：資訊準則。RDBMS的所有資訊都應在邏輯一級用同一個方法----表（Table）中的值顯示出來。而且，每個表的表名，表中的列名和域名等，都是用系統內的資料字典表中的值表示的。資料字典本身是一個描述後設資料的關聯式資料庫。

準則2：保證訪問原則。依靠表名、主碼和列名的組合，應保證能夠訪問關聯式資料庫中的每個資料項值。保證訪問原則規定，關係系統不能採用面向機器的定址法，而必須採用關係系統獨有的關聯定址的訪問模式.

準則3：空值的系統化處理。空值是"不知道"或"無意義"的值，它不是一個具體的值（如零、空字串等）。空值的概念很重要，在全關係DBMS中支援空值，就是要用一個系統化的方式處理空值。

準則4：基於關係模型的動態聯機資料字典。資料庫的描述在邏輯級上應和一般資料採用相同的表示方法，使得授權使用者能使用查詢一般資料所用的關係語言來查詢資料庫的描述資訊。本準則不僅使每個使用者只需學習一種資料模型，而且授權使用者還可方便地擴充字典，使之變成完備、主動的關係資料字典。

準則5：統一的資料子語言準則。一個關係系統可以有幾種語言和多種終端使用方法。但必須有一種語言，該語言的語句可以表示為具有嚴格語法規則的字串，並能全面地支援以下定義：資料定義、檢視定義、資料操作（互動式或程式式）、完整性約束、授權、事務處理功能（事務的開始、提交和退回）。關係方法是高度動態的，處於頻繁的執行處理之中。因此，沒有必要把說明的功能分為若干種語言來實現。關聯式資料庫是一體化的資料子語言，它使程式設計師可首先互動地除錯資料庫語言，除錯正確後再嵌入程式中，從而可大大提高程式設計師的生產效率。

準則6：檢視更新準則。所有理論上可更新的檢視也應該允許由系統相同更新。"一個檢視在理論上是可更新的"指的是，存在一個與時間無關的演算法，該演算法可無二義性地把對此檢視的更新要求轉換為對基本表的更新序列。

準則7：高階的插入、修改和刪除操作。把一個基本關係或匯出關係作為單一的操作物件處理。這不僅適合於資料檢索，而且適合於資料的插入和刪除。以關係為操作物件不僅簡化了使用者查詢，也為系統進行查詢最佳化提供了很大的餘地。該準則對於獲得有效的分散式事務處理也是十分重要的，可避免從遠端結點傳送一條記錄就要發出一次請求，實現一次請求傳送一個關係，從而節省通訊代價。

準則8：資料的物理獨立性。無論資料庫的資料在儲存表示或存取方法上作何變化，應用程式和終端活動都保持邏輯上的不變性。

準則9：資料的邏輯獨立性。當對基本關係進行理論上資訊不受損害的任何變化時，應用程式和終端活動都保持邏輯上的不變性。

準則10：資料完整的獨立性。關聯式資料庫的完整性約束條件必須是用資料子語言定義並儲存在資料字典中，而不是在應用程式中定義。除了實體完整性和參照完整性外，具體的關聯式資料庫還可能有反映業務政策和管理規章的完整性約束條件。這些完整性條件都應該能用高階的資料子語言定義，並能存入資料字典，從而，當約束條件變化時，只需改變資料字典中定義的完整性語句，而不會邏輯上影響應用程式和終端活動。

準則11：分佈獨立性。對於如下兩類具體問題：其一，原來的DBMS只管理非分散式資料，現在要引入了分散式資料；其二，原來的DBMS能管理分散式資料，現在要改變原來的資料分佈。在這兩種情況下，由於RDBMS具有特定的資料子語言，都能使應用程式和終端活動保持邏輯不變性。

準則12：無破壞準則。如果一個關係系統具有一個低階（一次一個記錄）語言，該語言不能破壞或繞過完整性準則和用高階關係語言表達的約束條件。以上這十二條準則都以準則0為基礎，但僅有準則0是不夠的。

目前，雖然還沒有一個DBMS產品是全關係型的，但隨著人們對資料庫技術研究的進一步深入，加上軟體執行環境的改變，相信以後一定會出現越來越好的全關係型的DBMS，以滿足人們各類應用場合對資料庫產品的需求。

1974年，IBM的Don Chamberlin和Ray Boyce將Codd關聯式資料庫的12條準則的數學定義以簡單的關鍵字語法表現出來，里程碑式地提出了SQL（Structured Query Language）語言

  引用完畢。

     可以看出是SQL是用簡潔的語言完成了底層物理資料的對映。資料庫是和作業系統打交道的，甚至和硬體打交道CPU、記憶體和磁碟。我們日常經常看到的一個SQL居然會把資料庫拖死，其實就是因為SQL寫的不好，把伺服器的所有資源全部調動起來，導致資源耗盡了。是資料庫的問題嗎？是SQL的問題嗎？絕對是用的人的問題。

    今天看到一篇文章《資料庫奔潰的時候，沒有一個慢SQL是無辜的》如果使用者不在乎奔潰，那麼這能怪誰呢？

    資料庫沒人用，不會出問題。用的好也不會出問題。大家可以看看微信、支付寶、百度、谷歌等等很少、幾乎不出問題。資料量不大嗎？不是而是大家都能遵守最起碼的開發規範，正確使用SQL。而不是肆無忌憚的使用，比如給redis來一個keys *，也一樣出事。

     所以如果不是硬體損壞、（資料庫我一向反對使用虛擬機器、容器）不是虛擬化問題。那麼資料庫上發生的效能問題幾乎全是使用不當造成的。

    按照規範使用，即安全生產，那麼我們也幾乎不太可能出現問題。這個規範對於大的網際網路公司來說不是問題，因為這是基本素質。如果違反怎麼辦？按照規章制度處罰。三大紀律八項注意如果對違反的沒有處理，那麼軍隊怎麼得到擁護呢？

    《史記·高祖本紀》：“與父老約，法三章耳；殺人者死，傷人及盜抵罪。餘悉除去秦法。