爲什麼「基於集合的方法」比「程序方法」更好？

Question

我非常渴望知道真正的原因，但從googling獲得了一些知識。

感謝adavnce

Answer 1

因爲SQL是編寫程序代碼，真是可憐的語言，因爲SQL引擎，存儲和優化設計，使其有效的裝配和連接的記錄集。

Answer 2

因爲使用基於集合的方法進行SQL開發符合數據模型的設計。 SQL是一種非常基於集合的語言，用於從數據構建集合，子集，聯合等。在開發TSQL時記住這一點通常會導致更自然的算法。 TSQL提供了很多可用的過程化命令，這些命令在普通SQL中不存在，但不要讓它轉換爲過程方法。

這使我在注覺得從羅勃·派克我喜歡引用的一個對編程C本：

數據占主導地位。如果你選擇了正確的數據結構並且組織得很好，算法幾乎總是不言而喻的。數據結構，而不是算法，是編程的核心。

SQL數據庫和我們查詢它們的方式基本上是基於set的。因此，我們的算法應該如此。

從更加實際的角度來看，SQL服務器在考慮基於集合的方法時進行了優化。索引，存儲系統，查詢優化器以及其他通過各種SQL數據庫實現進行的優化，如果您只是通過基於集合的方法告訴他們所需的數據，而不是指定您希望如何以程序化方式獲取數據。讓SQL引擎擔心獲取數據的最佳方式，您只需要擔心告訴它需要哪些數據。

Answer 3

（請注意，這不只是適用於SQL Server，但因爲他們是我會離開你的標籤）

因爲，在一般情況下，數百人年的開發時間已經到了數據庫引擎和優化器以及它可以訪問數據的實時統計信息的事實已經導致它比用戶在爲給定的請求提供處理數據的最佳方式方面更好。

所以說我們要實現（與基於集合的方法），並讓它決定如何做到這一點，我們一般達到更好的效果比拼出究竟如何到provess的數據，逐行。

例如，假設我們從表A到表B有一個簡單的內部連接。在設計時，我們通常不知道'哪一個回合'最有效處理：保留所有值的列表在A方，並通過B匹配它們，反之亦然。但查詢優化器將在運行時知道表中的行數，最近的統計數據可能會提供有關這些值本身的更多信息。所以這個決定顯然是在運行時更好的，由優化器做出。

最後，請注意，我已經在這篇文章中提出了一些'一般的東西 - 總會有些時候我們比優化器更好地知道，並且在這種時候我們可以提供暗示（NOLOCK等）。

Answer 4

基於集合的方法是聲明式的，所以您不會描述工作的完成方式，只會描述您希望結果的樣子。服務器可以在多種策略之間做出決定，以便如何與您的請求相符，並希望選擇一種效率高的策略。

如果您編寫程序代碼，那麼在某些情況下，該代碼至多不會那麼優化。

Answer 5

正如每個人都解釋過的，讓SQL引擎幫助你，相信它非常聰明。 如果您不使用編寫基於集合的解決方案並用於開發過程代碼，那麼您必須花費一些時間，直到編寫完善的基於集合的解決方案。這是大多數人的障礙。如果你想開始編寫集合基礎解決方案，一個提示是，不要想着你可以用行做什麼，並開始思考你可以用collumns做什麼，並且練習功能語言。