<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Relational-Model on Tarragon</title><link>https://tarrragon.github.io/blog/tags/relational-model/</link><description>Recent content in Relational-Model on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Mon, 31 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/relational-model/index.xml" rel="self" type="application/rss+xml"/><item><title>Relation（關係）</title><link>https://tarrragon.github.io/blog/backend/01-database/sql/knowledge-cards/relation/</link><pubDate>Mon, 31 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/backend/01-database/sql/knowledge-cards/relation/</guid><description>&lt;p>Relation 是一組欄位固定、由若干列構成的資料集合。&lt;strong>列&lt;/strong>（row）指橫向的一筆資料，&lt;strong>欄&lt;/strong>（column）指縱向的一個位置——這是台灣的用法，簡體中文的 SQL 資料多半用「行」指這裡的列、用「列」指這裡的欄，兩套剛好對調。資料表是它的一種，而查詢過程中產生的中間結果也是——&lt;a href="https://tarrragon.github.io/blog/backend/01-database/sql/knowledge-cards/outer-join/" data-link-title="Outer Join（外連接）" data-link-desc="想確認 LEFT / RIGHT / FULL 各自保護哪一側、或連接之後有些人從名單上消失時">outer join&lt;/a> 產出的那一份就是，它比來源表多了幾列補 NULL 的。&lt;/p>
&lt;p>這個詞值得單獨認一次，因為中文的「關係」在日常語言裡指人或事物之間的聯繫，與這裡的意思無關。它是 relation 的譯名，指的是那個集合本身。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>&lt;strong>把中間結果也當成關係，多層查詢才讀得動。&lt;/strong> 書店的 &lt;code>FROM 顧客 LEFT JOIN 訂單&lt;/code> 走完之後，得到的那一份有姓名與訂單編號兩種欄位、四列（佳穎兩列、宗翰與雅文各一列而訂單編號是 NULL）。它沒有對應的資料表，沒有名字，也不會被寫進磁碟——而後續的 &lt;code>WHERE&lt;/code>、&lt;code>GROUP BY&lt;/code> 全部對它操作，不對原本那兩張表操作。&lt;/p>
&lt;p>這個性質讓查詢可以層層套疊：一個連接的輸出可以當下一個連接的輸入，子查詢的輸出可以當外層的來源。也因為每一層的輸入與輸出都是同一種結構，&lt;a href="https://tarrragon.github.io/blog/backend/01-database/sql/knowledge-cards/query-optimizer/" data-link-title="Query Optimizer（查詢最佳化器）" data-link-desc="想知道是誰決定了執行順序、或為什麼同一段查詢換個時間變慢時">query optimizer&lt;/a> 才有重排的空間——只要最後產出的關係一樣，中間怎麼組合都合法。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/backend/01-database/sql/knowledge-cards/outer-join/" data-link-title="Outer Join（外連接）" data-link-desc="想確認 LEFT / RIGHT / FULL 各自保護哪一側、或連接之後有些人從名單上消失時">Outer join&lt;/a> 是這組運算裡的一個，它產出的關係比來源表多了補 NULL 的那些列。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>判斷現在處理的是不是還是原表，看列數與欄位。連接之後列數可能變多（一列配到多列就複製一次）、欄位是兩邊合起來的、還可能出現來源表裡沒有的空缺。三者任一成立就表示已經離開原表了。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>多層查詢的判讀方式是逐層檢查每一層的欄位與列，而不是想像最後那一張表。把每個 &lt;code>JOIN&lt;/code> 都想成「兩張表配對」在第三張表之後就失準，因為那時左邊已經是前兩層累積出來的關係。&lt;/p></description><content:encoded><![CDATA[<p>Relation 是一組欄位固定、由若干列構成的資料集合。<strong>列</strong>（row）指橫向的一筆資料，<strong>欄</strong>（column）指縱向的一個位置——這是台灣的用法，簡體中文的 SQL 資料多半用「行」指這裡的列、用「列」指這裡的欄，兩套剛好對調。資料表是它的一種，而查詢過程中產生的中間結果也是——<a href="/blog/backend/01-database/sql/knowledge-cards/outer-join/" data-link-title="Outer Join（外連接）" data-link-desc="想確認 LEFT / RIGHT / FULL 各自保護哪一側、或連接之後有些人從名單上消失時">outer join</a> 產出的那一份就是，它比來源表多了幾列補 NULL 的。</p>
<p>這個詞值得單獨認一次，因為中文的「關係」在日常語言裡指人或事物之間的聯繫，與這裡的意思無關。它是 relation 的譯名，指的是那個集合本身。</p>
<h2 id="概念位置">概念位置</h2>
<p><strong>把中間結果也當成關係，多層查詢才讀得動。</strong> 書店的 <code>FROM 顧客 LEFT JOIN 訂單</code> 走完之後，得到的那一份有姓名與訂單編號兩種欄位、四列（佳穎兩列、宗翰與雅文各一列而訂單編號是 NULL）。它沒有對應的資料表，沒有名字，也不會被寫進磁碟——而後續的 <code>WHERE</code>、<code>GROUP BY</code> 全部對它操作，不對原本那兩張表操作。</p>
<p>這個性質讓查詢可以層層套疊：一個連接的輸出可以當下一個連接的輸入，子查詢的輸出可以當外層的來源。也因為每一層的輸入與輸出都是同一種結構，<a href="/blog/backend/01-database/sql/knowledge-cards/query-optimizer/" data-link-title="Query Optimizer（查詢最佳化器）" data-link-desc="想知道是誰決定了執行順序、或為什麼同一段查詢換個時間變慢時">query optimizer</a> 才有重排的空間——只要最後產出的關係一樣，中間怎麼組合都合法。</p>
<p><a href="/blog/backend/01-database/sql/knowledge-cards/outer-join/" data-link-title="Outer Join（外連接）" data-link-desc="想確認 LEFT / RIGHT / FULL 各自保護哪一側、或連接之後有些人從名單上消失時">Outer join</a> 是這組運算裡的一個，它產出的關係比來源表多了補 NULL 的那些列。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>判斷現在處理的是不是還是原表，看列數與欄位。連接之後列數可能變多（一列配到多列就複製一次）、欄位是兩邊合起來的、還可能出現來源表裡沒有的空缺。三者任一成立就表示已經離開原表了。</p>
<h2 id="設計責任">設計責任</h2>
<p>多層查詢的判讀方式是逐層檢查每一層的欄位與列，而不是想像最後那一張表。把每個 <code>JOIN</code> 都想成「兩張表配對」在第三張表之後就失準，因為那時左邊已經是前兩層累積出來的關係。</p>
]]></content:encoded></item></channel></rss>