Notion 資料庫「反複雜」使用指南

by Daria Kolesnikova

2024/02/01：新增「本文目錄」與「結語：適可而止的複雜」兩個部分。
2024/01/28：重新修訂全文，增加若干內容，使整體論述更清晰、完整。

讓我們進入「Simple Notion」系列的第三篇，同時也是最後一篇。這次我們要聊聊，最能夠代表 Notion 的關鍵元素：資料庫（database）。

一提到 Notion 你會想到什麼？沒錯，就是資料庫。資料庫就是 Notion 的代名詞。

Notion 在 2016 年就誕生了（你也可以說是 2013年，請參考維基百科關於 Notion 的「歷史與發展」），但直到 2018 年才大紅，為什麼？——因為加入了 database。

儘管在 UI 加入類似關聯式資料庫功能，並非 Notion 獨創。畢竟，在此之前，Airtable 已經是這方面的佼佼者。

但我們不得不承認，Notion 確實把資料庫玩出了新的高度。

系列：Simple Notion——我的 Notion 簡潔之道

使用 Notion 滿 3 年，為何我仍「不推薦」用它來管理你的人生？

少則得，多則惑：使用 Notion 時的兩個常見陷阱

Notion 資料庫「反複雜」使用指南

本文主旨與目標讀者

資料庫（database）無疑是 Notion 最強大的功能，但也是最複雜的。「過度使用」的結果，可能比不用還糟糕。

既然是「Simple Notion」系列文章，主軸仍會聚焦在「簡潔」二字。而講到簡潔使用 Notion，資料庫絕對是一個無法繞過的主要議題。

我希望不落俗套地，討論 Notion 資料庫的美麗與哀愁。並提供簡單有效的使用指南，讓你能夠避免「陷阱」，適度使用，從而真正發揮它的價值。

更重要的是：減少不必要的學習焦慮感。

目標讀者

本文目標讀者有二：

已使用過 Notion 資料庫，但覺得太複雜或心累，甚至想放棄的人。
剛開始學習 Notion 資料庫的人——尤其是「不想花太多時間」的人。

對！如果你真的不想要花太多時間學習 Notion 資料庫，恭喜你！你就是本文最核心的目標讀者XD

雖然我現在比較少用 Notion 資料庫——主要拿來寫作，但我覺得「適度使用」的話，它還是非常方便的。

相關內容：我在 Notion 的局部實現

而本文會告訴你，怎麼樣才能適度使用。

本文架構與主軸

為統一用語，本文中「database」皆指 Notion database。

我們要先講 Notion database 為什麼強大，然後再討論與之相關的「困境」，最後則是我對這些困境的解法與心得。

本文主軸是「Notion 資料庫簡潔之道」。因此，如同前兩篇，原則上不會有任何關於 Notion database 的詳細操作教學——這些是「術」。

想知道各種 database 使用技巧，可以上 YouTube，那裡有著海量的學習資源。

讓我們進入正題。

Notion 的心臟：資料庫

Notion database 真的很強大。可以說，光是 database 和六種 database view，就佔據了 Notion 一半以上的重要功能——以及複雜度。

雖然 Notion database 有借鑑 Airtable 之嫌，但 database view 之間的自由切換、資料的靈活呈現，則是任何剛接觸的人，都不得不讚嘆的強大應用模式。

同一個資料庫，可以是表格，也可以是看板，還可以是日曆，甚至是甘特圖。

這種「一個資料庫，多種呈現方式」的特性，讓 Notion database 有著無限的可能性。

用 Notion 就是為了 database

我認為，既然要使用 Notion，絕對是因為它強大的 database。

這東西大大滿足了喜歡收集資料，並將它們整理得井然有序且美觀的筆記愛好者！我也曾經是其中的一份子啦！☺️

不過就像前一篇說的，我不建議花太多時間在「美觀」上，這會沒完沒了：

這些元素可以讓你在視覺上感到富足，但從筆記效率與學習、實用角度來看，恐怕沒有多少幫助。光挑選這些「樣式」，就能花掉你不少時間，甚至讓人樂此不疲。

Craft——沒有 database 的 Notion？

第一篇我們曾討論過「Notion 替代品？」這個議題，並提到了這篇文章〈我用來取代 Notion 的筆記軟體：Craft〉。

Craft 被一部分人稱之為「沒有 database 的 Notion」，意味著它省去了 database 的複雜，但保留了其它吸引人的功能。（區塊、鏈接、樣式等）

我自己因為有訂閱 Setapp（Craft 有收錄其中），所以有短暫嘗試過幾次，但體驗不是很好。

相關文章：2023 那些我已不可或缺的「付費訂閱」推薦

主要是中文排版讓我覺得頗為零亂，而且字太小又沒有調整機制，這違背了我對筆記軟體排版的「三大基本要求」。

不過，Craft 的確是一個值得考慮的選擇，尤其是對於那些不想要太複雜的人。

學習 Notion database 的三大常見困境

綜上所述，我不禁會想：「沒有 database 的 Notion，我會想用嗎？」——平心而論，我的答案可能是「不會」。

換言之，database 無庸置疑是 Notion 的一大利器。我認為，想要充分感受 Notion 的魅力，學習 database 是不可或缺的一環。（個人觀點）

但是！怎麼用，才算是「剛剛好」？

我歸納了學習使用 Notion database 常見的三大困境。先了解它們，才好對症下藥。

困境一：學習門檻

如前所述，database 佔據了 Notion 一半以上的功能與複雜度。對於沒有太多時間深入研究的人而言，學習如何有效使用 database 可能是一個挑戰，甚至是一種焦慮。

而網路上的很多教學，進一步加劇了這個困境。

部分文章或 YouTube 影片，為了讓讀者、觀看者印象深刻，往往使用相對複雜或進階的技巧，藉以展現 Notion database 的強大功能。

這些 database 技巧印證了 Notion 的強大，但也可能間接增加了學習時的心理負擔。

回歸基本

五花八門的技巧讓「只想要簡單使用 Notion」的新手感到困惑與沮喪，誤以為不學習這些技巧，自己就無法善用 Notion。

這當然是一個錯覺。

這是為何我會寫下〈Notion 教學：10 個我最常用的 Markdown 語法與快捷鍵介紹〉一文，讓 Notion 的學習與應用，回歸基本。

毫無疑問，我認為 database 的使用，也應該回歸基本——但並不容易。

下面兩個困境，就能很好說明「簡單使用 Notion 資料庫」的困難之處。

困境二：不必要的複雜

說起「不必要的複雜」，軟體工程師可能頗有感觸，在開發上我們稱為「過度設計」。

複雜不一定是問題，少數情況就是要「井然有序的複雜」。但是，我們也常看到，很多時候的複雜，真的是脫褲子放屁，自找麻煩。

所謂「複雜」，指使用 Notion database 時五花八門的技巧，比如把「公式」欄位玩出各種花樣、為多個 database 建立複雜的關聯、為閱讀資料庫建立大量欄位，以及任何你看了會不禁發出「wow！」讚嘆的用法。

這些用法，乍看讓人驚艷、興奮，覺得 Notion 真是無所不能。

而我對此感到恐懼，因為我知道，這些技巧很容易讓人上癮。

誠然，Notion database 可以做很多事，但這也可能讓你不知不覺掉入了前一篇提到的「筆記架構師陷阱」：

這是一個逐漸「上癮」的過程，因為 Notion 創建新頁面與層級是如此地簡單，導致遇到新需求時，我就想要用「增加 Notion 元素、擴張筆記架構」的方式來應對，結果它愈長愈大，直到脫離了我的控制。

當複雜累積到一定程度，你會發現：你的 Notion database 已變得相當難以維護。

困境三：過度使用

一有新的筆記整理、分類需求，就立刻想到新增一個 database；或為既有的 database 新增一個甚至多個欄位。

這幾乎是所有 Notion 新手不可避免的困境，當然包括我。

因為實在太過經典且普遍，我們甚至可以把它當成「Notion 新手的必經之路」。

這樣做有什麼問題？相信過來人都懂，讓我舉一個自己的例子。

使用 Notion 做程式筆記

以前大量使用 Notion，主要就是為了學程式，所以有很多程式相關的筆記。這些筆記本來只有兩個 database：

學習筆記：技術類書籍、線上課程、文章的整理。
實作筆記：開發過程中遇到的問題與我的踩坑記錄。

這感覺不錯，但你可能已經猜到——兩個根本不夠用！至少對我而言不夠用。

光學習，可能要區分成「程式類」和「非程式類」。而不同素材如書、線上課、文章等等，我不希望它們歸納時沒有任何區別，因為這樣找起來或複習很麻煩。

於是，為了新的「子分類」，要麻再多開一個 database，不然就是多增加一些欄位作為區別。我甚至想把程式主題再進一步細分，比 Django、Docker、Python 等等。

如此反覆，我的學習筆記類 database 暴增為 6-8 個，其中有的欄位多、有的欄位少。

資料庫太多了！

後來，看著一堆 database，覺得自己好累，尤其在新增一則筆記時，不得不先思考：「呃……它應該放到哪個 db？」——好像已經太多了。

如果你有很多個 database 要維護，那你對它們得有一個相對清晰的概念與操作體系，才不容易作繭自縛。

但我必須說，至少在「學習」這一個主題，要透過清晰的體系來架構 database，恐怕相對困難。

為什麼？因為隨著學習的進展，知識體系往往也會不斷調整。以往的分類可能不再適用或滿足你，需要做出一定改變。

然而，database 是很「重」的，增加欄位可以，但想要把一部分的資料遷移到新的 database 或分配到不同層級，則麻煩很多。不僅需要你手動搬運（使用Move to），還需要處理搬運後新舊欄位不相容的問題。

此外，每新增一筆記錄，就要填上各個欄位的值，也是一件「看起來有條理，但對學習沒有太大助益」的苦力活。

雖然可以用模板等功能來簡化，但，你不累嗎？

無解的「分類」難題

我認為分類難題（為各種事物、概念等筆記找到分類上的明確歸屬）可以說是無解的——尤其當這些分類會隨著時間不斷變動的情況下。

而大量的 database，本質上就是一層又一層的分類，容易累死自己。

而這裡提到的「學習筆記」情境，正是一個在分類上容易不斷變動的主題。

不過話說回來，我覺得現實中大部分情況，也多是如此——分類就是會一直變動。只是快慢有所不同而已。

Notion 資料庫最適合的場景

當然，也有少數例外，比如年、月、週計畫的 database。或上述的「閱讀資料庫」，概念都相對明確，也不會有太多變動。

資料庫在時間上的主要變化，就只有筆記數量的增加而已。

這類情境我就很願意 database 來管理，因為分類簡單，且鮮少變動。目前用 Notion 管理我的文章寫作，正是如此。

無論如何，只要資料庫一多，新增筆記時你就必須先思考「我要新增到哪個 db？」，我感覺腦力成本高昂🤯

我的 Notion database 簡潔使用指南

想簡單且有效地使用 Notion database，我個人會貫徹下列原則。

不過這些原則，多少都會限制 database 的發揮——為了避免過度使用。

所以是「原則」，作為你需要時的指引。

一、能透過「新增欄位」達成的，就不新增資料庫

雖然欄位管理也是一個難題，但怎麼說都比新增一個獨立 database 來得輕量。

換句話說，當筆記架構變得複雜，需要更多手段來有效分類不同筆記時，建議優先選擇建立欄位而非新增 database。

二、欄位不要過多

雖然說能用新增欄位處理的就不要透過新增資料庫，但同時，也要盡可能讓每一個欄位都是必要的，而不是為了「看起來井然有序」或「看起來更完整」。

相關內容：不必要的欄位

畢竟填寫欄位的人是自己。即使有模板，要應付各種複雜的欄位與情況，模板可能也要很多樣，這些都不利於筆記的製作與維護。

一般而言，閱讀類的 database，最容易出現欄位過多的問題。

因為一本書有很多種屬性，非常適合透過 database 歸納與整理！比如封面、出版社、作者、出版年度、書籍分類、個人評價、名言摘錄等等，簡直沒完沒了。

但閱讀一本書，最重要的往往只有一件事——明白一些道理，然後有所行動。

三、減少進階功能的使用

Notion 資料庫關聯（Relation 與 Rollup）、公式欄位等等比較進階的功能，讓人感覺很厲害，有時候也確有妙用。但我覺得，少知道一點或許會比較好。

重劍無鋒，大巧不工。雖然不是最高竿的使用，卻可能會更加高效。

對，就是少用一點，讓自己不要太依賴這些功能。這有助於你維持一個「相對簡單」的筆記架構。

而我認為「相對簡單」才是 Notion database 的最佳使用狀態。

四、善用 view 與 linked database（重要！）

在我看來，善用資料庫的「view 分頁」，是善用 Notion database 的王道。

「view 分頁」和前述的 database view 略有不同，主要強調在同一個 database 下，建立複數個分頁：

這些分頁，可以是同一種 database view，比如都是表格（table），只是排序、篩選不同。
也可以是不同的 database view，比如一個是表格，一個是看板。

我的「寫作」database，第一頁是看板，而第二頁是「發文行事曆」——採 Calender view。不得不說，真的超好用！令我愛不釋手。

分頁：發文行事曆

相關內容：行事曆是好東西

雖然太多分頁也會造成困擾，但透過分頁建立不同條件、排序的 view，能讓 db 資料更加有效呈現，充分發揮看資料的視角。

兩相權衡，我認為非常值得。

Linked database 連結資料庫

如果分頁太多，就再開一個 linked database，你又多了一個呈現資料的「分身」。

在我看來，linked database 就是 Notion 資料庫中「第二偉大」的設計！它讓我們能夠在不同的頁面、不同的 database view，呈現同一份資料。

那第一偉大的設計是什麼？當然是上面提到的 view 分頁。

換句話說，其餘的 database 功能，看我看來都屬於 optional——需要時再學習即可。只有 view 分頁與 linked database 是必學的。

我認為善用 view 分頁與 linked database，就是用好 Notion database 的關鍵！

讓資料發揮最大價值

本文之所以如此推崇 view 分頁與 linked database，是因為它們能夠「讓現有資料發揮最大價值」。

它們都不需要新增欄位或 db，卻能讓我們更有效地呈現資料。

當檢視資料的需求或角度改變，只要把 view 刪除、變更即可，不會影響到資料本身。

這樣能有效地控制 database、欄位的數量，一定程度地避免過度使用。

因此，在新增 database 前，我們不妨先想想：「是不是新增一個 view 就能解決？」

五、固定架構

我覺得 Notion 資料庫最適合的，是那些「筆記架構相對固定」的場景，比如前面提到的年、月、週計畫這類的記錄。

年、月、週、天就是典型的時間劃分，你很難再生出一種全新的時間劃分方式。所以，database 的欄位設計與架構相對穩定。

而我們要做的，就是不斷增加筆記的「量」。這種場景，特別能發揮 database 在體系與分類上的優勢。

六、架構常變動的場景，我使用卡片筆記

前面已提及，學習筆記的架構很容易依不同階段而變動，採用 database 常常會讓我覺得過於笨重、趕不上變化。

此外，database 還有一個「複習不便」的致命傷。

所以我後來才狠心放棄了寫了 2 年的 Notion（我的筆記啊！哭），改用 Logseq 來做我的程式學習筆記，以適應快速變動的學習，並達到更有效的複習。

畢竟卡片筆記更像是「無固定中心的游擊隊」，有著更強的機動性。

關於「為什麼改用 Logseq 做程式筆記」，我們會再另篇討論。這裡只要提醒自己：

Notion database 不適合頻繁的架構遷移。

結語：適可而止的複雜

前面提到：「相對簡單」才是 Notion database 的最佳使用狀態。

而且，要能真的做到「相對簡單」，如你所見——可一點也不簡單。

有趣的是，這種「畫地自限」的使用方式，可能違背了你的直覺，甚至讓人感到不滿。

我完全可以理解。

因此，我願意再提出一個更加折衷的方案（價值觀）：適可而止的複雜。

適可而止的複雜

其實最理想的情況是，熟練地使用 Notion database，讓它發揮最大價值，同時不至於讓自己陷入困境。

在這個前提下，Notion 完全有能力勝任「稍為複雜」的任務，比如閱讀資料庫、寫作管理等等，同時讓人感覺非常井然有序。

但還是要小心，複雜終究有其代價——我們要讓結果配得上這個代價。

該如何拿捏，並沒有「標準答案」。尤其是 Notion 這種「自由度極高」的工具。

所以本文終究也只是一份「指南」，它的主要價值，在於你發現自己已經陷入困境時，能夠作為參考，並協助你及時調整。

題外話：Notion 並不適合做卡片筆記

正文已結束，我們來聊個題外話。

這部分跟本文主軸雖然沒有直接關係（但和 database 有關），我還是忍不住想說——Notion 真的不適合做卡片筆記。

我們先回顧一下〈Logseq 心得：一顆冉冉升起的「卡片筆記」新星〉提到卡片筆記的兩大原則：

元素化。
連結導向。

關鍵是第二個：連結。

Notion 的「連結」只做了一半

如你所知，Notion 資料庫有 Relation 欄位可以進行簡單的「資料庫關聯」，頁面開頭也有本頁的 backlinks 可供參考。

但這些功能，相比於「原生支援雙向連結」的卡片筆記軟體如 Logseq、Obsidian，在「有效實踐卡片之間的連結」這件事上，效果相去甚遠。

用 Notion 絕對可以做卡片筆記，但很難做得好。

所以你可以看到，關於用 Notion 做卡片筆記的文章、影片，大多都是點到為止，沒有深入探討，也很難做更進一步的應用。

畢竟，我們只需要簡單試想一下，當 Relation 欄位有著 100 個關聯的時候，這個欄位看起來會是如何？

而 100 個關聯對於 Logseq 等卡片筆記 app 而言，僅僅只是開始而已。

文章目錄