This is part 6 of 7 in the Notion database series. Read Part 5: Notion Database Views
Databases are so easy to make and weave in and out of your workspace pages. You can create and use linked views anywhere. Views of data are not restricted to a hierarchy. Remember your computer files. They live in one spot. You can make shortcuts but you have to manually create them every time. Databases are much more powerful and flexible. This is the data matrix at play. Any line of data can cross any context and surface in just the right way.
While the views are not restricted to the hierarchy, the database does have to live somewhere in the hierarchy. The database has a “home” in which it operates from. For most people, this won’t matter too much as you can call up a linked database from the spot you want to see it. However, there are a couple reasons why you should consider adopting the best practice of the “databasement.” This is where you keep all of your core databases in one place.
The first reason is just for organization. It puts all of the “back-end” components into one spot, making it very easy for you to know where to actually find the back end should you ever have to work on it. Most of the time, you can work from linked views exclusively. But sometimes, especially when you are truly modifying or at least auditing the back end, it’s easier to know exactly where you should go.
The second reason is much more important for teams but really for anyone who is sharing their workspace with other people – permissions. It’s MUCH easier to ensure security of your data when all of your data is one spot. One, because you can quickly audit and ensure that only the right people have the right access. But two, because people can’t accidentally “soft-side” in as easily. What do I mean by soft-siding?
When you check that only certain people have access to your data, you’re securing the castle gate. soft siding is when they gain access through another permission channel. It doesn’t even have to be malicious! But if your permission structure isn’t well thought out, it can be very easy to give someone unintended access when you didn’t mean to. groups are a perfect example. It’s much more scalable to give groups permission to different places throughout the workspace and then add people to their respective groups instead of adding each person individually to every place. But if your groups are nebulous, lacking definition and are used all over the place these are channels of weakness. Someone could add a person to a group because that group has access somewhere else in the workspace, not realizing that the same group also has a much higher clearance elsewhere. A “soft-side”.
It’s also much easier to make sure that people have access to the right data at scale. If Engineering has the projects database and People ops has the files database and Tasks is being shared individually from someone’s private sidebar – this becomes unsustainable very fast. A lot of the company members are not engineers but they need access to that Projects database that the Engineers have in their teamspace. You shouldn’t have to make them members of that teamspace because it’s not for them! Not to mention, there could be more sensitive information in a teamspace that only real team members should have access to.
So, what does a databasement look like? For most, just put them in one page where it makes sense and you know where to find them. If you already have databases elsewhere, just replace them with a linked view and then move the original. For companies at scale, we like to actually create a teamspace just for company data. This is especially useful when the company might have external contractors in and out of the workspace. It’s ALWAYS better to start with restriction of data and then expand as necessary.
Read Part 7: Notion Self-Referencing Filters