剛剛好：Notion database「反複雜」使用指南
文章目錄
by Daria Kolesnikova
讓我們進入「Simple Notion」系列的第三篇，同時也是最後一篇。這次我們要聊聊，最能夠代表 Notion 的關鍵元素。
提到 Notion 你會想到什麼？沒錯，database！
Notion 在 2016 年就誕生了（你也可以說是 2013年，請參考維基百科關於 Notion 的「歷史與發展」），但直到 2018 年才大紅，為什麼？——因為加入了 database。
儘管在 UI 加入類似 SQL table 元素與互動操作，並非 Notion 獨創。畢竟，在此之前，Airtable 已經是這方面的佼佼者。但我們不得不承認，Notion 確確實實把 database 玩出了新的高度。
系列：Simple Notion——我的 Notion 簡潔之道
- 使用 Notion 滿 3 年，為何我仍「不推薦」用它來管理你的人生？
- 少則得，多則惑：使用 Notion 時的兩個常見陷阱
- 剛剛好：Notion database「反複雜」使用指南
本文主旨與目標讀者
我希望不落俗套地，討論 Notion 的 database——它的美麗與哀愁。
既然是「Simple Notion」系列文章，主軸仍會聚焦在「簡潔」二字。而講到簡潔使用 Notion，database 絕對是一個無法繞過的主要議題。
何謂不落俗套？
看過前兩篇的讀者或許能預見，我又要來說一說 database 的缺點了。嚴格而言，應該稱之為「濫用 database 的困境」。
Notion database 是如此的強大，以至於能夠讓 Notion 在眾多筆記軟體中脫穎而出。甚至，有了 database，你簡直不能說 Notion 只是一個筆記軟體了。
說它是一個資料平台也不為過。
目標讀者
這篇文章是為了「已使用過 Notion database 但覺得太複雜或心累」的讀者而寫。
因為我就是其中一員！至少曾經是。
雖然現在已經較少使用 Notion database（只拿來管理文章草稿和工作會議記錄），但我覺得這個「利器」，適度使用還是非常方便的。
本文架構與主軸
我們要先講 Notion database 為什麼強大，然後再討論與之相關的「困境」，最後則是我對這些困境的解法與心得。
本文的主軸是「Notion database 使用之道」。因此，如同前兩篇，文中不會有任何關於 Notion database 的詳細操作教學——這些是「術」。
想知道各種 database 使用技巧，可以上 YouTube，那裡有著海量的學習資源。
讓我們進入正題。
Notion 的核心——database
Notion database 真的很強大。可以說，光是 database 和六種 database view，就佔據了 Notion 一半以上的重要功能——以及複雜度。
雖然 Notion database 有借鑑 Airtable 之嫌，但 view 與 view 之間的自由切換、資料的靈活呈現，則是任何剛接觸的人，都不得不讚嘆的強大應用模式。
Notion 的本體就是 database
換句話說，我認為要用 Notion，絕對是因為它強大的 database。
這東西大大滿足了喜歡收集資料，和把它們整理得井然有序而且美觀的筆記控！我也曾經是這一份子啦☺️
不過就像前一篇說的，不建議花太多時間在「美觀」上，這會沒完沒了：
這些元素可以讓你在視覺上感到富足，但從筆記效率與學習、實用角度來看，恐怕沒有多少幫助。光挑選這些「樣式」，就能花掉你不少時間，甚至讓人樂此不疲。
Craft——沒有 database 的 Notion？
第一篇我們曾討論過「Notion 替代品？」這個議題，並提到了這篇文章〈我用來取代 Notion 的筆記軟體：Craft〉。
Craft 被部分人稱之為「沒有 database 的 Notion」，意味著它省去了 database 的複雜，但保留了其它吸引人的功能。
我自己因為有訂閱 Setapp（Craft 有收錄其中），所以有短暫嘗試過一下，但體驗不是很好。
主要是中文排版讓我覺得頗為零亂，而且字太小又沒有調整機制，這違背了我對筆記軟體的「三大基本要求」。
但扣除這些，我也不禁在想：「沒有 database 的 Notion，我會想用嗎？」——我深表懷疑。
簡言之，database 無庸置疑是 Notion 的一大利器。我認為，想要充分感受 Notion 的魅力，學習 database 是不可或缺的一環。
但是！怎麼用，才算是「剛剛好」？
我歸納了學習使用 Notion database 常見的三大困境。先了解它們，才好對症下藥。
困境一：學習門檻
如前所述，database 佔據了 Notion 一半以上的功能與複雜度。對於沒有太多時間深入研究的人而言，學習如何有效使用 database 可能是一個挑戰，甚至是一種焦慮。
而網路上的很多教學，進一步加劇了這個困境。
部分文章或 YouTube 影片，為了讓讀者、觀看者印象深刻，往往使用相對複雜或進階的技巧，藉以展現 Notion database 的強大功能。
這些 database 技巧印證了 Notion 的強大，但也可能間接增加了學習時的心理負擔，讓部分新手感到困惑與沮喪，覺得自己無法有效應用 Notion。
這也是為什麼我會寫下〈Notion 教學：10 個我最常用的 Markdown 語法與快捷鍵介紹〉這樣的文章，讓 Notion 操作回歸基本。
毫無疑問，我認為 database 的使用，也應該回歸基本——但並不容易。
困境二：不必要的複雜
說起「不必要的複雜」，軟體工程師可能頗有經驗，在開發上我們稱為「過度設計」。
複雜不一定是問題，少數情況就是要「複雜且有系統地處理」。但是，我們也常看到，很多時候的複雜，真的不是那麼必要。
這裡所謂的「複雜」，可以指使用 database 欄位各種進階技巧，比如把「公式」欄位玩出各種花樣，或巧妙建立 database 間的關聯（對應欄位是 Relation 和 Rollup）。或任何你看了會不禁發出「wow！」讚嘆的用法。
誠然，Notion databse 可以做很多事，但這也可能讓你不知不覺掉入了前一篇提到的「筆記架構師陷阱」：
這是一個逐漸「上癮」的過程，因為 Notion 創建新頁面與層級是如此地簡單，導致遇到新需求時，我就想要用「增加 Notion 元素、擴張筆記架構」的方式來應對，結果它愈長愈大，直到脫離了我的控制。
「擴張筆記架構」最典型的情況，就是增加 database 的數量和欄位！甚至是它們之間的關聯。
這也就是下面要講的——過度使用。
困境三：過度使用
一有新的筆記整理、分類需求，就立刻想到新增一個 database；或為既有的 database 新增一個甚至多個欄位。
這幾乎是所有 Notion 新手不可避免的困境，當然包括我。
這樣做有什麼問題？相信過來人都懂，讓我講講自身的經驗。
使用 Notion 做程式筆記
以前大量使用 Notion，主要就是為了學程式，所以有很多程式相關的筆記。這些筆記本來只有兩個 database：
- 學習筆記：技術類書籍、線上課程、文章的整理。
- 實作筆記：開發過程中遇到的問題與我的踩坑記錄。
這感覺不錯，但你可能已經猜到——兩個根本不夠用！至少對我而言不夠用。
光學習，可能要區分成「程式類」和「非程式類」。而不同素材如書、線上課、文章等等，我不希望它們歸納時沒有任何區別，因為這樣找起來或複習很麻煩。
於是，為了新的「子分類」，要麻再多開一個 database，不然就是多增加一些欄位作為區別。我甚至想把程式主題再進一步細分，比 Django、Docker、Python 等等。
如此反覆，我的學習筆記類 database 在數量上增加到了 6-8 個，其中有的欄位多、有的欄位少。
Database 太多了！
後來，看著一堆 database，覺得自己好累，尤其在新增一則筆記時，不得不先思考：「呃……它應該放到哪個 db？」——好像已經太多了。
如果你有很多個 database 要維護，那你對它們得有一個相對清晰的概念與操作體系，才不容易作繭自縛。
但我必須說，至少在「學習」這一塊，要透過清晰的體系來架構 database，恐怕相對困難。
為什麼？因為隨著學習的進展，知識體系往往也會不斷調整。以往的分類可能不再適用或滿足你，需要做出一定改變。
然而，database 是很「重」的，增加欄位可以，但想要把一部分的資料遷移到新的 database 或分配到不同層級，則麻煩很多。不僅需要你手動搬運（使用Move to），還需要處理搬運後新舊欄位不相容的問題。
此外，每新增一筆記錄，就要為欄位選擇各項值，也是一件「看起來有條理，但實際對學習沒有直接助益」的苦力活。
這些當然可以用模板等功能來簡化，但，你不累嗎？
無解的「分類」難題
我認為分類難題（為各種事物、概念等筆記找到分類上的明確歸屬）可以說是無解的——尤其當這些分類會隨著時間不斷變動的情況下。
而大量的 database，本質上就是一層又一層的分類，容易累死自己。
還是要再強調一下，這裡我類比的情境是「學習筆記」，一個在分類上容易不斷變動的主題。但我覺得，其實現實中大部分情況都是如此——分類就是會一直變動。
當然，也有例外，比如年、月、週等計畫的 database，概念之間是相對分明的。
無論如何，只要 database 一多，新增筆記時你難免就要先思考「我要新增到哪個 db？」，複習或搜尋時也要想著「這件事應該是記在哪個 db？」
腦力成本高昂。
我的 database 減法
簡單使用 Notion database 比簡單使用 Notion 要來得容易，我個人會貫徹下列原則。
不過這些原則多少都會限制 database 的發揮，所以是「原則」，作為需要時的指引。
一、能透過「新增欄位」達成的，就不新增 db
雖然欄位管理也是一個難題，但怎麼說都比新增一個獨立 database 來得輕量。
換句話說，當筆記架構變得複雜，需要更多手段來有效分類不同筆記時，建議優先選擇建立欄位而非新增 database。
二、欄位不要過多
雖然說能用欄位處理的就不要透過 db，但欄位的增加也必須適合可止，盡可能讓每一個欄位都是必要的，而不是為了「看起來井然有序」或「看起來更完整」。
畢竟填寫欄位的人是自己。即使有模板，要應付各種複雜的欄位與情況，模板可能也要很多樣，這些都不利於筆記。
就我的經驗看來，閱讀類的 database，最容易出現欄位過多的問題。
因為一本書有很多種屬性，非常適合透過 database 歸納與整理！比如封面、作者、出版社、出版年度、書籍分類、個人評價、名言摘錄等等，簡直沒完沒了。
但閱讀一本書，最重要的往往只有一件事——獲得最大程度滿足與改變自身行動。
三、減少進階功能的使用
db 關聯、公式欄位等等比較進階的功能，讓人感覺很厲害，有時候也確有妙用。但我覺得，少知道一點或許會比較好。
重劍無鋒，大巧不工。雖然不是最高竿的使用，卻可能會更加高效。
四、善用 view 與 linked database
過濾、排序、view 等功能分頁，我覺得它們是「必要之惡」——這是讚美☺️
view 分頁
雖然太多分頁也會造成困擾，但透過分頁選擇不同 view、過濾條件、排序方式等，確實能讓 db 資料更加有效呈現，充分發揮看資料的視角，我認為非常值得善用。
如果分頁太多了，推薦再開一個 linked database，這下又多了一個呈現資料的分身。
總之，我認為善用 view 分頁與 linked database，就是用好 Notion database 的一大關鍵！
在新增 db 或新增欄位之前，我們不妨先想想：「是不是新增一個 view 就能解決？」
五、固定架構
我覺得 Notion database 最適合的，是那些「筆記架構相對固定」的場景，比如前面提到的年、月、週計畫這類的記錄。
年、月、週、天就是典型的時間劃分，你很難再生出一種全新的時間劃分方式。所以，database 的欄位設計與架構相對穩定。
而我們要做的，就是不斷增加筆記的「量」。這種場景，特別能發揮 database 在體系與分類上的優勢。
六、架構常變動的場景，我使用卡片筆記
前面已提及，學習筆記的架構很容易依不同階段而變動，採用 database 常常會讓我覺得過於笨重、趕不上變化。
此外，database 還有一個「複習不便」的致命傷。
所以我後來才狠心放棄了寫了 2 年的 Notion，改用 Logseq 來做我的程式學習筆記，以適應快速變動的學習，並達到更有效的複習。
畢竟卡片筆記更像是「無固定中心的游擊隊」，有著更強的機動性。
關於「為什麼我改用 Logseq 做程式筆記」，我們會再另篇討論。這裡只要提醒自己：「database 不適合太過頻繁的架構遷移。」
題外話：Notion 並不適合做卡片筆記
正文已結束，我們來聊個題外話。
這部分跟本文主軸雖然沒有直接關係（但和 database 有關），我還是忍不住想說——Notion 真的不適合做卡片筆記。
我們先回顧一下〈Logseq 心得：一顆冉冉升起的「卡片筆記」新星〉提到卡片筆記的兩大原則：
- 元素化。
- 連結導向。
關鍵是第二個：連結。
我知道，Notion database 有 Relation 欄位可以進行簡單的 db 間關聯，頁面開頭也有本頁的 backlinks 可供參考。
但這些功能，相比於「原生支援雙向連結」的卡片筆記軟體如 Logseq、Obsidian，在「有效實踐卡片之間的連結」這件事上，效果相去甚遠。
用 Notion 絕對可以做卡片筆記，但很難做得好。
只要試想一下，當 Relation 欄位有著 100 個關聯的時候，這個欄位看起來會是如何？
而 100 個關聯對於 Logseq 等卡片筆記 app 而言，僅僅只是開始而已。
相關文章