This is part 7 of 7 in the Notion database series. Read Part 6: Keep Your Notion Data Secure
Databases are unique in Notion because you can not only manage the database on the table level with all of the metadata visible and customized – but each item is itself a page. You can open any of the pages and enter content within the page. It’s a very nice separation of data and metadata. But what if…we put database views inside the page thats already in a database. Is that even legal?
Yes. yes, very much so.
This is where some serious sauce is made. Databases not only matrixed across the hierarchy, they can matrix across…each other. You can open a database page and enter any relevant data to that object, including linked views! For example, you can open a Project’s page from the Project database and start collaborating on it with your teammates (or just yourself). You can then insert a linked view to files and filter it to show files relevant for that Project. Or bring in tasks and filter for tasks that are relevant to that project!
But how can you filter precisely? What do you tag a database page with to give it that hook to filter on? Well, you can tag it with exactly the place you want it to show up in – for example you can “tag” a file with the projects by name, and then adjust the filter in the projects to only show files with that projects name. It works but it’s super manual and fragile. Instead, level up your Notion and use Relations. Relations allow you to connect one database to another. You basically create a portal between Projects and Tasks. And through that portal, you can connect a specific task to a specific Project, or 5 specific files to 1 specific project. The relation property opens up these connections by giving you a cell next to each page where you can choose the page from the other database you want to relate it to.
So now you’ve got a very precise and intuitive “tagging” mechanism. Even better that you’re hooking it to the actual object itself. This means that anything you change about that object, like it’s name, won’t break the connection. If the task “take out the trash” is related to the Project “chores” but then you change the project name to “House Duties” – the relation will reflect this change and “take out the trash is now related to “House Duties”. That’s because the object never really changed, just it’s name. The connection runs deeper than the name.
Alright so let’s end with a huge unlock called “self-referencing” filters. In fact, the definition of “meta” is self-referencing so these could easily be called meta filters. But the community calls them self-referencing so that’s the lingo you should expect!
A benefit of using databases is being able to use templates. You can prefill pages in a database and load that template when you create a new page in the database. And you can create as many templates in each database as you want. You can also create templates in a database that include linked views from other databases. The page, as a template, doesn’t quite exist yet until you make it. So you have a Project template, and then you create a new page with that template and name the Project. So do you have to make the template, then go and change the filter of the linked views within? No! You can set this up at the template level by filtering the linked view by its relation to that database and choosing the template page. When the template loads, the linked view will be related to the newly created page, not the template! The filter is self-referencing because within its own page contents, it has a filter to itself.