When I first started using Notion, it was a bit confusing. The layout and pages of the app were straightforward, but the power of Notion, the way databases worked was unique.
My first use of a database type structure was on an Atari 800 in 1981. In the 90’s I used Microsoft Access and SQL Server for business development, along with Excel and MS Project, from there, MySQL was my go-to for a decade.
If you’re familiar with relational databases, but a bit confused by Notion, this is for you.
Structure
Databases in Notion are similar to other databases.
They have tables, and rows/records, and columns/fields, except:
Tables are called Databases.
These Databases are collections of Rows.
Yet the Rows are Pages.
And the Columns are called Properties.
In addition:
Pages can have other Pages inside them.
Pages can even have other Databases (Tables) inside them, or Views of Databases.
Viewing a Page shows all of the Properties in it, plus any other pages in it, or Databases, or Views of Databases.
It’s a rabbit hole.
They have a primary key, but it is fixed, and has a data type of “Title”.
Confused yet?
This terminology can be troubling when learning Notion if you come from a legacy database background, so what’s the best way to get in the groove?
Start with the complexity of the solution you are creating. One can build just about anything in Notion if they try. A To-Do List dashboard? No problem. A robust CRM? Yup. Like a legacy database, it just comes down to getting the structure/schema correct when building it.
How many Databases does your solution require? Just follow standard database normalization rules.
Eliminate repeating groups in individual Databases.
Create a separate Database for each set of related data.
Identify each set of related data with a primary key (the unique, readable Title).
Use a Database for sets of values that apply to multiple records. This can be seen with Notions Select and Multi-Select properties, which themselves are tiny, hidden Databases of values that are used often.
Joins
“What about Joins?” you ask.
In SQL we know that a Join is used to return Rows from two or more Tables.
SELECT Orders.ID, Customers.Name, Customers.Address, Orders.Date
FROM Orders
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID;
That query would return the ID and Date from the Orders table, and the Name and Address from the Customers table, where the CustomerID is the same in both.
In Notion we would be returning Pages from Databases. In order to do that in our example, we would create a Relation between our Orders database and our Customers database. This Relation is constant, always there and ready to be used. It only returns one thing though, the Name of the Page (type Title). The Orders Name would show up as a Property in the Customers Page, and, if you have enabled Two-Way Relations, the Customers Name would show up as a Property in the Orders Page.
“What about that Customers Address though?”
That’s where Rollups come into play. Rollups are simply Anything Else You Want To See in a Relation between Databases.
In order to see the Customers Address, you would simply add a Rollup in the Orders database, where the Relation is the Customers database, and the Property is the Address.
And that’s it.
Things are just named differently, and returning data from multiple sources works a bit different, but overall fairly similar, and once it clicks and makes sense, it’s easy.
