Notion Database Property 完整教學：Property、Database 與欄位類型怎麼選？

先看這篇會更有感：Notion Database 教學。如果你已經知道 Database 是什麼，但卡在欄位怎麼配，這篇就是接下來那一步。

🎯 解答先行

操作簡報：Notion Database Property 不用一次學完全部。對大多數新手來說，先懂 Title、Status、Select、Multi-select、Date、Person、Relation、Formula 這 8 種就夠你把大部分資料庫建穩。

很多人搜尋 notion property 或 notion database，真正想解的通常不是名詞問題，而是：我到底要怎麼設欄位，資料庫才不會越用越亂？

很多人把 Notion Database 做亂，不是因為 View 不會切，而是 Property 一開始就設太多、太散、太像想到什麼就加什麼。

比較穩的做法是：

1. 先決定這個資料庫要管什麼
2. 再決定每一欄是拿來描述、分類、排程還是關聯
3. 最後才補進階欄位

---

Notion Database Property 是什麼？

Property 就是資料庫裡的欄位。

你可以把它想成「每一筆資料要帶哪些資訊」。例如一筆任務，可能會帶：

• 名稱
• 狀態
• 截止日
• 負責人
• 優先級

如果沒有 Property，Database 就只是一串頁面清單。有了 Property，這些頁面才會變成可以排序、篩選、統計、關聯的系統。

所以 Property 的本質不是「多一欄資訊」，而是讓資料變得可管理。

---

Notion Property、Database、Database Property 差在哪？

這三個詞很容易混在一起，但實際上層級不同。

名詞	中文理解	你可以怎麼想
Notion Database	資料庫	一整張表，負責收納同一類資料
Notion Property	屬性 / 欄位	每一筆資料要帶的資訊
Notion Database Property	資料庫欄位	某個資料庫裡實際設定出來的欄位

例如你有一個「內容資料庫」：

• 這整個表就是 Database
• 狀態、發布日、主題、關鍵字 都是 Property
• 這些欄位放在內容資料庫裡，就是 Database Property

所以你可以這樣判斷：

Database 管資料集合，Property 管每筆資料的結構。

新手最常犯的錯，是還沒想清楚 Database 要管理什麼，就先狂加 Property。結果欄位看起來很多，真正能拿來篩選、排序、排程的欄位卻很少。

---

Notion Database Properties Help Center 在查什麼？

如果你看到官方文件或搜尋結果寫 Notion database properties help center，它通常是在講所有欄位類型的官方說明。

Notion 官方文件會把 Property 分成很多種，例如：

• Text、Number、URL、Email、Phone
• Select、Status、Multi-select
• Date、Person、Files
• Formula、Relation、Rollup
• Created time、Created by、Last edited time、Last edited by
• Button、ID、Place

但如果你是新手，不需要一次全部學完。比較實用的順序是：

1. 先學會 Title、Status、Select、Date
2. 需要協作再加 Person
3. 資料庫之間真的要互相連動，再加 Relation、Rollup
4. 最後才用 Formula、Button、ID 做自動化與進階整理

官方文件適合查「這個欄位能做什麼」，但真正做系統時，你更該問的是：

這個 Property 之後會不會被拿來篩選、排序、排程、統計或自動化？

如果答案是否定的，它可能只是備註，不一定值得變成一個欄位。

---

新手先懂這 8 種 Property

先說結論：你不需要一開始就碰完所有欄位類型。先把下面這 8 種用順，已經可以做出大部分工作流。

Property 類型	最常拿來做什麼	什麼情況先用它
Title	每筆資料的主名稱	每個資料庫都一定要有
Status	追蹤進度	任務、流程、專案
Select	單一分類	優先級、類型、來源
Multi-select	多重標籤	主題標籤、屬性標記
Date	時間安排	截止日、發布日、建立日
Person	責任歸屬	負責人、協作者
Relation	連到另一個資料庫	任務連專案、文章連關鍵字
Formula	自動計算或顯示狀態	到期提醒、進度判斷、欄位組合

如果你連第一個資料庫都還沒建，先回去看 Notion Database 教學。如果你已經有資料庫，但欄位越加越亂，就繼續往下看。

---

各種 Property 類型到底怎麼選？

1. Title：每個資料庫的主鍵

Title 是每一筆資料的主名稱，不能被其他欄位取代。

最常見錯誤是：有人把真正的名稱寫進 Text 欄，導致資料不好找、模板不好套、列表也不好看。

原則很簡單：

• 任務資料庫：用任務名稱
• 內容資料庫：用文章標題
• CRM 資料庫：用客戶名稱

2. Status：適合追流程，不適合塞太多狀態

Status 很適合用來表示一筆資料「現在進到哪一步」。

例如：

• 待處理
• 進行中
• 已完成

最常見錯誤是把狀態拆太細，結果每個人理解都不一樣。對小型團隊或個人系統來說，通常 3 到 5 個狀態 最穩。

3. Select：只能選一個的分類

Select 適合處理「每次只能有一種答案」的欄位。

常見場景：

• 優先級：高 / 中 / 低
• 內容類型：教學 / 比較 / 工具文
• 來源：GSC / Bing / 社群靈感

如果一筆資料可能同時屬於多個分類，就不要硬用 Select，直接改 Multi-select。

4. Multi-select：標籤很多時才用

Multi-select 適合用在「一筆資料可以被多個標籤描述」的情況。

例如一篇文章同時屬於：

• Notion
• SEO
• 自動化

但要注意，Multi-select 很容易失控。標籤一多，最後就會變成每個人都在發明自己的分類系統。比較穩的做法是：

• 先限制標籤用途
• 只保留真的拿來篩選的標籤
• 不要把備註、心得、分類全塞進標籤

5. Date：時間欄位不要只留一個

很多人只建一個 Date，結果後面自己都搞不清楚這個日期到底是建立日、截止日，還是發布日。

比較穩的做法是欄位名稱直接寫清楚：

• Due Date
• Publish Date
• Meeting Date

欄位名稱越清楚，後面做 Filter / Sort 越不容易亂。

6. Person：責任人一定要有

只要資料庫會牽涉協作，Person 幾乎都是基本欄。

因為沒有負責人，很多資料最後都會變成：

• 大家都看得到
• 但沒有人真的要處理

即使只有你自己在用，Person 也可以保留，因為之後擴充團隊時不用重做結構。

7. Relation：當資料開始互相影響時再上

Relation 是 Notion Database 真正開始有系統感的地方。

最常見用法：

• 任務資料庫連到專案資料庫
• 文章資料庫連到關鍵字資料庫
• 客戶資料庫連到提案資料庫

但新手最容易犯的錯，是太早把所有東西都連在一起。結果資料庫還沒穩，關聯就已經長得像蜘蛛網。

原則是：先把單一資料庫跑順，再補 Relation。

8. Formula：先拿來做簡單判斷，不要一開始寫太複雜

Formula 很強，但也最容易把資料庫做成只有你自己看得懂。

新手先用最簡單的 3 類就夠：

• 顯示是否到期
• 組合多欄位文字
• 根據日期顯示狀態

如果你的 Formula 已經長到自己三天後看不懂，通常代表這個邏輯該拆回流程，而不是繼續堆在欄位裡。

---

任務、內容、CRM 資料庫，欄位怎麼配最穩？

任務資料庫

建議欄位	類型	目的
Task Name	Title	任務主名稱
Status	Status	追蹤進度
Priority	Select	判斷先後順序
Due Date	Date	排程
Owner	Person	責任歸屬
Project	Relation	對應哪個專案

這類資料庫的重點是：少一點欄位，多一點可執行性。

內容資料庫

建議欄位	類型	目的
Title	Title	文章名稱
Status	Status	草稿 / 審稿 / 發布
Topic	Select	主題歸類
Tags	Multi-select	補充標籤
Publish Date	Date	排程日期
Keyword	Relation	對應 SEO 關鍵字

如果你平常會寫 SEO 文章，內容資料庫和關鍵字資料庫最好分開，再用 Relation 連起來，這樣後面才容易維護。

CRM 資料庫

建議欄位	類型	目的
Client Name	Title	客戶名稱
Stage	Status	洽談階段
Source	Select	客戶來源
Contact Date	Date	上次聯絡時間
Owner	Person	負責窗口
Projects	Relation	關聯專案

CRM 最常見的錯不是欄位不夠，而是把所有細節都塞進單一資料庫。資料變多後，客戶、專案、提案通常要拆開處理。

---

新手最常犯的 5 個錯誤

1. 一開始就把所有欄位加上去

這通常不是完整，而是混亂的開始。先建最小可用欄位，真的有重複需求再補。

2. 用 Text 代替結構化欄位

例如把狀態寫在備註欄、把日期寫成文字。這樣後面就無法篩選、排序與自動化。

3. Select 和 Multi-select 用反

只能有一種答案的欄位，用 Select。可能同時有多個標記的，再用 Multi-select。

4. 欄位名稱太抽象

像 Date 1、Status New、Info 這種命名，三週後你自己都忘了它是幹嘛的。欄位名稱要直接對用途負責。

5. 太早上 Formula 和 Relation

不是不能用，而是要在資料結構穩定後再補。很多人問題不在技術不會，而是核心流程還沒想清楚就開始做進階設計。

---

一句話判斷：現在該加哪種 Property？

如果你現在邊做邊卡，可以用這個判斷表：

你現在想解的問題	優先加哪種 Property
我要知道它現在做到哪	Status
我要分類	Select / Multi-select
我要安排時間	Date
我要知道誰負責	Person
我要把兩個資料庫連起來	Relation
我要讓欄位自動判斷	Formula

大原則只有一句：先讓資料可用，再讓資料變聰明。

---

Property 會怎麼影響搜尋、篩選和自動化？

Notion Database 能不能變成真正的工作系統，關鍵不在頁面數量，而在 Property 設得夠不夠乾淨。

如果 Property 設對，你可以做到：

• 用 Status 篩出還沒完成的任務
• 用 Date 排出本週要處理的內容
• 用 Select 看不同主題的文章數量
• 用 Relation 把文章、關鍵字、社群貼文連起來
• 用 Formula 自動判斷是否逾期

如果 Property 設錯，你就會遇到：

• 想篩選，但資料都寫在備註裡
• 想排序，但日期被寫成文字
• 想自動化，但狀態欄位沒有標準格式
• 想整合 API，但同一種資料有三種寫法

所以 Notion Database 的核心不是「有很多欄位」，而是「欄位能不能支撐你之後的操作」。

這也是為什麼 Property 設計不是小事。它會直接決定你的 Notion 系統能不能長期維護。

---

FAQ

Notion Property 是什麼？

Notion Property 是資料庫裡的欄位。它用來描述每一筆資料的狀態、分類、日期、負責人、關聯或計算結果。

Notion Database Property 是什麼？

Property 就是資料庫欄位。它決定每一筆資料要帶哪些資訊，讓資料可以被排序、篩選、關聯與計算。

Notion Database 和 Property 有什麼差？

Database 是整個資料集合，Property 是資料庫裡的欄位。你可以把 Database 想成一張表，把 Property 想成這張表的每一欄。

新手第一個資料庫先建哪些欄位？

通常先建 Title、Status、Select、Date、Person 就很夠用。先跑順，再慢慢補 Relation 和 Formula。

Select 和 Multi-select 怎麼選？

如果一筆資料只能屬於一個分類，用 Select；如果可能同時有多個標籤，再用 Multi-select。

Relation 要一開始就用嗎？

不一定。比較穩的做法是先把單一資料庫結構跑順，確認真的有跨資料庫需求，再補 Relation。

Formula 適合新手嗎？

適合，但先從簡單判斷開始，例如到期提醒、文字組合、狀態顯示。不要一開始就把複雜邏輯全塞進 Formula。

如果你下一步想把欄位、View 和資料庫結構串起來，建議接著看 Notion Database 教學、Notion Filter / Sort 教學、Notion API 教學。