The Art of Titling a Notion Database

Josh Redd

September 23, 2024
Part 3/7: Thoughtful naming of Notion databases defines database objects and influences workspace organization, impacting efficiency in digital knowledge management.

This is part 3 of 7 in the Notion Database series. Read Part 2: Properties of a Notion Database

In a basic sense, making and using databases is pretty straightforward. Using them effectively takes some sophistication, but largely, the concept of rows and columns is not complicated. And it’s pretty easy to get started once you see one working. You create it, you title it, and off you go. But what do you title it? What if I told you, this was actually an important step in the process?

Titling databases is important, not just for clarity but because it effectively defines the objects within. What do I mean by objects? I mean the things within, effectively the pages. But it’s not just the page, it’s what the page represents, the object it represents. A Project database contains Projects, the objects (pages) within should all be representations of Projects. I say representation because the real Project is the work you and everyone else is doing to accomplish a collection of similar tasks. The database page (also called a record) stands in for that project within your digital workspace. It represents that project. It is a database object and it belongs in a database most likely titled “Projects.”

You see what I’m getting at. The title of a database is important. Don’t feel crazy if you ever have to stop and think what the name should be – it means you’re in the right headspace. When you label a drawer “towels,” you don’t want to find dog toys in there. This is all simple enough but there will inevitably come a point where you have to make some decisions on how to structure your workspace “back-end” and what databases you will need to create. It not only comes down to what goes where, but you also have to consider which databases should be related to each other and dealing with rollups.

A commonly difficult structure for people to figure out is how to make sense of the following five things:

  • Files
  • Notes
  • Meeting Notes
  • Events
  • Tasks

You might immediately say that the first three could be the same database. Or maybe just the first two. Or maybe the 2nd and 3rd. But then the 3rd and 4th work well together. But the last two are things I want to see on one calendar, thus one database. Which is right?

Let me make a case for differentiating Files and Notes. To me, Files are formal, evergreen reference documents with distilled knowledge. Notes on the other hand, are informal, transient, ad hoc thoughts, opinions, musings, brainstorms, etc. In my opinion, your Files database is a representation of formal organizational knowledge. While proper tagging can differentiate the two within the same database, you also have to consider related views down the road. When you want to show files related to a project, I am of the opinion that you should expect items with a little more weight to them. Here’s the thing, you can also do the same thing with related notes alongside the files! But if you only use one database but have to depend on tagging filter in most of your linked views to only show one or the other, its a good indication that they should be separated.

At the end of the day, we’re getting a little subjective here and other factors like templates, workflows, relations, permissions and such can influence the decision. This is where it starts to become an art. But I have clear definitions and distinctions between Files and Notes. If the line gets fuzzy, it’s imperative that you define what each one is so that people know exactly where to put something and where to find it. This is the essence of giving a database the right title.

The title defines the objects within.

Events and Tasks can be tricky because a lot of people want to see things on one calendar but they’re vastly different objects except for having a date and being action oriented. The properties you would maintain on either database would be very different and to combine the two can get confusing. This is actually another indication to separate databases – when half the time, half the properties don’t apply at all to the object. In my opinion, it’s not worth the hassle. Keep them separate.

I’ll spare the problem illustration of the Notes, Meeting Notes, and Events and just say that I like to absorb meeting notes into Events and just take the notes within the event object. The context of the note is clear, it was from a meeting. More specifically I actually prefer to call my Events Database “Calendar” because it contains anything “Date Anchored” whether it’s a zoom call, an in person meeting, a conference, or even an OOO notice. People have one calendar to look at. Again, it can be subjective but it’s important that you have clear definitions to prevent overlap.

One last note, I’ve given a couple indications of when a database probably needs to be separated into two. One indication for the reverse scenario, where you should probably consolidate rather than split databases, is when you title them with a category or an adjective (If you’re titling them as true representations of what’s within). For example if you have a database called “Engineering Projects” – that’s a bright red flag that you’re probably dealing with multiple Projects databases. And unless there is a legitimate reason to do so (permissions mainly) then you should consolidate them for the sake of the Global Database concept. (That’s the next article)

Read Part 4: The Global Notion Database Concept