30 秒重點
- 判準 1 句話：這是 1 種獨立存在的東西，還是某個既有東西的狀態？ 是狀態就加欄位。
- 多數人開太多資料庫，是因為把想要分開看，當成了需要分開存。這兩件事用視圖就能拆開。
- 視圖不會產生新的資料庫。同 1 份資料可以有任意數量的視圖，各自篩選、排序、分組。
- 真的該開新資料庫的情況有 4 種：它有自己的生命週期、它會被 3 個以上不同的東西引用、它的欄位跟現有的幾乎不重疊、它的每一筆都需要自己的內頁放東西。
- 資料庫開太多的代價不在畫面，在於每多 1 個就多 1 條要維護的關聯。
在 Notion 裡面做系統，最常遇到的決策就是這個：來了 1 個新需求，我到底要開 1 個新的資料庫，還是在現有的資料庫加 1 個欄位？
選錯的代價不對稱。加欄位選錯，之後刪掉就好。開資料庫選錯，你會多出關聯、多出要同步的地方、多出 1 個沒人維護的角落。
我自己整理系統的時候就開太多過。我當時的直覺是：只要這件事需要被記錄，就給它 1 個資料庫。結果做到一半才發現，有好幾個資料庫裡面永遠只有 3 到 5 筆，而且每筆都得手動接回主流程。
判準：這是 1 種東西，還是 1 個狀態？
先看例子。
你需要記錄這份稿子審過了沒。直覺是開 1 個審核資料庫，把每次審核記成 1 筆。
但審核不是 1 種獨立存在的東西，它是稿子的 1 個狀態。稿子從草稿走到審核中，再走到已通過，審核只是這條路上的 1 段。
所以正確做法是在稿件資料庫加 2 個欄位：1 個狀態、1 個審核人。需求就解決了，而且完全沒有新增任何關聯。
反過來看客戶這個例子。客戶在專案結束之後還在，而且同 1 個客戶會有很多個專案，它有自己的生命週期。這種才需要自己的資料庫。
是狀態就加欄位，是獨立的東西才開資料庫。
3 個問題，問完就有答案
不確定的時候，照順序問這 3 題：
- 它會自己存在嗎？ 把主體刪掉之後，這筆資料還有意義嗎？稿子刪了，那次審核紀錄就沒意義，所以審核是狀態。客戶還在，所以客戶是獨立的東西。
- 同 1 筆會被很多不同的東西用到嗎？ 客戶會被專案、報價、發票同時引用，這種適合獨立。只有 1 個地方會用到的，加欄位就好。
- 它的欄位跟現有的重疊多嗎？ 高度重疊代表它其實是同 1 種東西的不同階段，應該用狀態欄位區分，而不是拆成兩個資料庫。
3 題裡面有 2 題以上答不會或不多，就加欄位。
你想要的通常是分開看，不是分開存
這是我覺得最值得講的一點。
很多人開新資料庫的真正動機是：我想要有 1 個地方只看得到待辦、1 個地方只看得到這個月的、1 個地方只看得到某個人負責的。
這些全部都是怎麼看的需求，跟資料存在哪裡無關。加一個視圖不會多出一個資料庫，資料還是同 1 份，只是換一種篩選、排序與分組的看法。
換句話說，你想要的那 5 個不同畫面，可以全部建在同 1 個資料庫上。資料只有 1 份，畫面有 5 個。
把這件事想通，通常可以直接砍掉一半的資料庫。
那什麼時候真的該開新資料庫？
符合下面任何 1 條，就開：
| 條件 | 例子 |
|---|---|
| 它有自己的生命週期，主體結束後還在 | 客戶、廠商、人員 |
| 它會被 3 個以上不同的東西引用 | 客戶被專案、報價、發票引用 |
| 它的欄位跟現有資料庫幾乎不重疊 | 財務收支跟內容排程 |
| 它的每一筆都需要自己的內頁去放東西 | 會議紀錄要放逐字稿與附件 |
最後那一條容易被忽略。Notion 的資料庫本質上是頁面的集合，每 1 筆都是 1 個可以往下寫的頁面。如果你的資料只需要幾個欄位、不需要內頁，那它很可能只是欄位而已。
開太多的代價
多 1 個資料庫，不只是側邊欄多 1 行。
每多 1 個，你就多 1 條要拉的關聯、多 1 個要決定要不要雙向的判斷、多 1 個以後改架構時要一起改的地方。3 個資料庫的時候感覺不出來，8 個的時候你會發現自己在維護系統，而沒有在用系統。
關聯該怎麼拉、哪些其實不用拉，我另外寫在Notion 的關聯到底要拉幾條。
還有 1 個實務上的建議：不確定的時候先加欄位。欄位加錯了刪掉就好，資料庫開錯了要搬資料、要重接關聯，成本高很多。先往可逆的那一邊走。
動手前的順序
先寫流程，再決定資料放哪裡。
把這個需求實際發生時的步驟寫出來，從誰觸發、到誰處理、到最後誰要看到結果。寫完之後你會發現，多數需求根本沒有新增任何一種新的東西，它只是既有流程上多了 1 個狀態、或是多了 1 個要篩出來的畫面。
我在內容批次規劃裡面也用同 1 個順序：先確定實際會怎麼跑，再決定要用什麼結構去接。
📌 資料來源：Notion 官方說明〈資料庫介紹〉。最後確認日期：2026-09-20。Notion 功能更新頻繁，實際操作前建議再對照 1 次官方頁面。
如果你已經開了一堆資料庫，現在想整理卻不知道該從哪裡拆，可以填這份Notion 需求表單，我會看你的工作方式跟想解決的問題，評估適合的頁面架構與資料庫設計。
