ORM 的產出與運算發生的位置

ORM 把資料表對應成類別、把資料列對應成物件。篩選條件寫成屬性的比較式，框架把它翻譯成 SQL 的 WHERE 子句。

 1from sqlalchemy import select
 2from sqlalchemy.orm import Session
 3
 4stmt = select(Customer).where(Customer.age > 18)
 5print(stmt.compile(engine))
 6# SELECT customer.id, customer.name, customer.age FROM customer WHERE customer.age > ?
 7
 8with Session(engine) as s:
 9    rows = s.scalars(stmt).all()
10    print([type(r).__name__ for r in rows], [r.name for r in rows])
11    # ['Customer'] ['A']

stmt 本身還沒有做任何運算，它是一段待送出的查詢。運算在資料庫那一端完成，回來的每一列被包成一個 Customer 實例——所以拿到的是物件，可以呼叫它的方法、走訪它關聯到的其他物件。

DataFrame 的產出與運算發生的位置

pandas 這一側的同一件事：

1df = pd.DataFrame({"id": [1, 2], "name": ["A", "B"], "age": [20, 10]})
2df[df["age"] > 18]
3#    id name  age
4# 0   1    A   20

df["age"] > 18 先算出一個布林陣列 [True, False]，外層的取值用這個陣列挑出要留下的列。整段運算發生在這個程序的記憶體裡，沒有連線、沒有 SQL、沒有另一個系統參與。

回來的是一張新的表格，不是一組物件。它可以繼續被篩選、被合併、被彙總，因為表格正是這些操作接受的輸入。

分辨 ORM 與 DataFrame 的訊號：回傳值的形狀、連線物件、查詢送出的時機

外觀相似的方法串接底下，有三個分得開的訊號。

回傳值的形狀。 一組各自獨立、可以呼叫方法的實例，是 ORM 那一側；一張有欄有列、可以繼續被篩選與彙總的表格，是 DataFrame 那一側。

有沒有連線物件。 資料庫端的工具一定要先有一個連線或 session，因為運算要送去別的地方。pandas 的操作不需要：資料一旦載進 DataFrame，之後每一步都在這份記憶體裡的副本上進行，原本那個資料庫或檔案後來有沒有變動都不影響它。

查詢送出的時機。 ORM 允許先把查詢組好、之後才送出，所以「描述」與「執行」是兩個時刻。pandas 的每一行敘述當場就算完，中間沒有待送出的狀態。

各語言生態的資料庫存取分層：手寫 SQL、查詢建構器、ORM

自己寫 SQL、用建構器組 SQL、用 ORM 對應物件，這三層在多數語言生態裡都找得到對應的套件，名字不同而分層一致。各語言的代表工具，以及手寫 SQL 再細分成驅動、結果對映、從 SQL 產生程式碼的方式，見 1.17 應用程式存取資料庫的工具分層。

DataFrame 這一層則是額外的第四種，它不在上面那條線上——它處理的是已經在記憶體裡的表格，與資料庫的存取方式無關。一般的增刪改查應用不使用它，那是 ORM 的位置。

延伸閱讀：SQL 與 pandas 的寫法對應、運算發生的位置、pandas 的記憶體邊界、ORM 的查詢反模式

這兩側共用的抽象：ORM 產生的 SQL 與 DataFrame 的方法，做的是同一組操作。8.4 SQL 子句與 pandas 方法的對應：篩選、連接、分組彙總、視窗函數，以及空值、索引與順序的語意差異 給篩選、連接、分組彙總與視窗函數在兩邊的實測比對，以及空值、索引與順序這幾處對應斷掉的位置。

分界本身：兩側的差異全部從「運算發生在哪一端」推出來。8.2 運算發生的位置 寫這條軸怎麼決定容量上限與失敗形態，以及選邊時要問的三個條件。

選了記憶體端之後的上限：8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給資料量的估算方法與越過之後的三個方向。

ORM 那一側的失敗形態：延遲載入什麼時候把一次請求變成一百次查詢，在 backend 模組一的查詢反模式。那一篇把 N+1 與長交易列成可診斷的清單，並給出每請求的查詢次數預算。

換介面重寫一次同樣的邏輯因此是划算的練習：邏輯已經想清楚了，剩下的是查另一套語法怎麼寫。

篩選、連接、分組彙總與視窗函數的兩邊寫法

以下的 emp 兩邊是同一份資料，一邊在 SQLite 裡、一邊在記憶體的 DataFrame 裡。

篩選：挑出符合條件的列

1SELECT name FROM emp WHERE salary > 150

1emp[emp["salary"] > 150][["name"]]

連接：把兩張表按鍵值接起來

1SELECT e.name, d.dname FROM emp e JOIN dept d ON e.dept = d.dept

1emp.merge(dept, on="dept")[["name", "dname"]]

分組彙總：每一組收斂成一列

1SELECT dept, MAX(salary) AS m FROM emp GROUP BY dept

1emp.groupby("dept", as_index=False)["salary"].max().rename(columns={"salary": "m"})

視窗函數：算出分組的統計值並保留原本的每一列

1SELECT name, salary - AVG(salary) OVER (PARTITION BY dept) AS d FROM emp

1emp.assign(d=emp["salary"] - emp.groupby("dept")["salary"].transform("mean"))[["name", "d"]]

transform 是這一組裡最值得記的：它與 agg 的差別正是視窗函數與 GROUP BY 的差別——agg 讓每一組收斂成一列，transform 把組的統計值攤回組內的每一列。

這四組在同一份資料上跑出來的結果逐格相同。

對應斷掉的位置：分組時的空值、索引、順序

有三個地方兩邊的語意本來就不同，照著逐句翻譯會在這裡失準。

空值在分組時的去留。 SQL 的 GROUP BY 把 NULL 當成一組，pandas 的 groupby 預設把分組鍵是缺值的那些列排除掉，於是那一組在結果裡整組消失。

1t.groupby("k").size()                 # {'x': 1}          缺值那一組消失了
2t.groupby("k", dropna=False).size()   # {'x': 1, nan: 2}  與 SQL 一致

同一段邏輯照著翻譯過來，統計結果會少掉一整組而且不會報錯。這是篩選、連接、分組彙總與視窗函數這幾組對應之外最容易靜默出錯的一項。

索引。 DataFrame 的每一列有一個索引，它獨立於欄位存在，而且會在 groupby、merge 之後改變。SQL 沒有對應的概念。翻譯過來的程式碼常常需要 reset_index() 或 as_index=False，那幾個呼叫處理的正是索引這個 SQL 沒有的狀態。

順序。 SQL 的查詢結果在沒有 ORDER BY 時不保證順序。DataFrame 的列有位置順序，而且多數操作會保留它。所以「相同的結果」在順序這一維上兩邊本來就不可比——可比的是集合，而集合的比較要先各自排序才成立。

延伸閱讀：運算發生的位置、ORM 與 DataFrame 的分辨、SQL 的視窗函數與語言設計、pandas 的記憶體邊界

這兩個介面為什麼會分家：一邊把運算交給資料庫，一邊在自己的記憶體裡算。8.2 運算發生的位置 寫這條分界怎麼決定容量上限，以及選邊要問的三個條件。

同一個對比在 SQL 那一側怎麼講：transform 對 agg 的差別就是視窗函數對 GROUP BY 的差別。SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列 用輸出的單位當判斷標準，並示範相鄰的定義漏掉分區之後會跨到別的組上。

從產出認出手上是哪一個介面：8.3 ORM 與 DataFrame 的分辨：回傳值的形狀、連線物件與查詢送出的時機 寫兩者的回傳值形狀差在哪，以及分得開它們的三個訊號。

這套代數在 SQL 那一側怎麼設計：關聯代數的組合規則決定了子句的先後、連接的左右與分組的鍵，而那些規則各有一處與直覺相反。SQL：這個語言為什麼長這樣 從語言的宣告式性質推導這一整組規則，並另外處理文字之外的四方（識別字規則、引擎的寬鬆度、權限、最佳化器）。

換介面之後接手的新限制：SQL 那一側沒有記憶體上限的問題，換到 DataFrame 就有了。8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給估算方法與越過之後的三個方向。

三個分開的地方

列有沒有順序。 DataFrame 的列從頭到尾有一個位置，可以問「第三列是什麼」。關係沒有順序這個屬性，SELECT 回來的列要靠 ORDER BY 才排得出來。

誰在算。 對 DataFrame 的每一個操作在自己的行程裡執行，資料先整批進記憶體；對關係的操作交給資料庫引擎，程式收到的只有結果。上限因此不同——一邊是這台機器的記憶體，一邊是資料庫的儲存。

寫下的是動作還是描述。 DataFrame 的程式碼是一串照順序發生的動作：載入、篩選、合併。SQL 寫下的是要什麼結果，怎麼算由引擎決定。這一條是 SQL 這個分類每一篇的起點。

概念位置

DataFrame 在 SQL 那個分類裡的角色是對照組。宣告式這個性質單獨看不出形狀，跟一段逐步執行的程式並排才清楚——同一件事，一邊每一行指定下一步做什麼，一邊只描述要什麼。

兩邊的底層是同一套 關聯代數，所以多數操作對得上；對不上的地方正好落在上面那三項差別上。

往下走

宣告式與逐步執行的完整對照、以及三種順序的分工，在 SQL.1 宣告式的紅利與代價。同一組操作在兩種介面上的四組對應與對應斷掉的三個位置，在 python 模組八 8.4。