1.2Databases: the real power of Notion
The essentials in 30 seconds
- Row = page, column = typed property: each row opens as a full page, each column has a type (text, number, date, select, person, relation…).
- Type from the start: the type determines filters, relations and automations — a Date field, not «Monday» as free text.
- One dataset, several views: Table, Kanban, Calendar, Gallery, Timeline and List show the same data from the right angle, with no duplication.
Running mini-case — Lina structures her follow-up in Oran
Lina used to track digitalisation projects in a bulleted list that could filter nothing. She creates a «Projects» database: Task (title), Status (select: To do / In progress / Done), Due date (date), Priority (select), Owner (person). Each row becomes a project page with its notes. Then she adds a Kanban view by Status for steering and a Calendar view by Due date for deadlines.
Continued from case 1.1 — Lina moves from pages to structured data.
1. A smart table
What sets Notion apart from a notepad: databases. A database is a smart table where each row is a full page and each column is a typed property: text, number, date, select, checkbox, person, file, relation… The data is structured, so it can be filtered, sorted and exploited — far beyond a bulleted list.
Lina opens a row of her «Projects» database: it is a real page, with the meeting notes and attachments of the project — no more blind bulleted list.
2. One dataset, several views
The game-changer is views: the same database displays as a Table (spreadsheet), a Kanban (columns by status, Trello-style), a Calendar (by date), a Gallery (visual cards), a Timeline (schedule) or a List — without ever duplicating data. You see the same data from the angle that suits each use.
Lina steers in Kanban by Status in the morning and checks deadlines in Calendar in the afternoon: same projects, two angles, zero duplication.
3. Typing well: the decision that determines everything
Choosing the right property types from the start is decisive: it is what will later make filters, relations and automations possible. A static «block» table (text boxes) filters nothing; a well-typed database can be exploited.
Lina sets Due date as Date (not «Monday» as text) and Status as Select: her «this week» filters and her Kanban by Status work first time.
🔎 Concrete example — 🔎 Concrete example — A task database
The right field types.
Task (title)
Status → Select (To do / In progress / Done)
Due date → Date
Priority → Select
Owner → Person
→ Kanban view (by Status) + Calendar view (by Due date).Reading: Lina sees the same projects in Kanban and in Calendar.
Lesson: a Date field, not «Monday» as free text.
Section vocabulary
- Database
- A Notion database: a table where each row is a page and each column is a typed property.
Simple example: Lina's «Projects» database (Status, Due date, Owner).
What it is not: a static «block» table in free text, which cannot be filtered.
Reflex: data to exploit = database, not block table.
- Property (field)
- A database column, with a type (text, number, date, select, checkbox, person, file, relation…).
Simple example: Due date as Date and Status as Select in Lina's setup.
What it is not: everything as free text, unusable.
Reflex: type each field according to its real nature.
- View
- A display of a database: Table, Kanban, Calendar, Gallery, Timeline, List — same data, different angle.
Simple example: Lina's Kanban by Status and Calendar by Due date.
What it is not: a second copied table to «see things differently».
Reflex: one view per use, never a copied table.
- Kanban (board)
- A column view by status (to do / in progress / done) for moving cards by drag and drop.
Simple example: Lina's morning steering of projects, card by card.
What it is not: a frozen bulleted list that cannot be reordered visually.
Reflex: group by Status, move as you go.
- Property type
- The nature of a field, which determines what you can do with it (filter by date, sum numbers, link…).
Simple example: The due Date that enables Lina's «this week» filter.
What it is not: «Monday» written as text, unfilterable.
Reflex: the right type at creation, not after.
In practice — In practice — Create your first database
- Insert a database («/table» or full-page database) to manage a real need (tasks or projects).
- Define the properties with the right types: Status (select), Due date (date), Priority (select), Owner (person).
- Enter a few rows, then open a row: notice that it is a full page (you can write in it).
- Add a Kanban view (grouped by Status) and a Calendar view (by Due date) on the same database.
Ready-to-say script — framing a database before creating it (1 min)
«Before entering anything, let's define the structure: which columns, which type for each — Status as select, Due date as date, Owner as person. Five minutes of framing now, otherwise impossible filters later.»
To say before any database creation, in pairs or as a team.
Copy-paste template — database framing
DATABASE: _______________ (e.g. Projects)
TITLE: _______________
FIELD 1: _______________ → type _______________
FIELD 2: _______________ → type _______________
FIELD 3: _______________ → type _______________
PLANNED VIEWS: Table [ ] | Kanban by _______________ [ ] | Calendar by _______________ [ ]
RULE: no free text for a date / a status [ ]Existing list to reuse
Do not convert without thinking: rebuild the structure as a database, type the columns, then enter or paste the data (or import a CSV) — like Lina with her old bulleted list.
Team follow-up in Oran
Lina adds Owner (person) and Priority (select): everyone filters «their» projects and the weekly steering happens in a shared Kanban.
Small personal use
Even for yourself: three well-typed fields (Status, Due date, Priority) beat ten free-text columns.
Large volumes ahead
If linked data and calculations will dominate (CRM, production), note now that Airtable will take over (level 2) — Notion remains the workspace.
✓ Best practices
- Structure (types) before entry.
- Type each field correctly.
- Several views, never several tables.
✗ Common pitfalls
- Block table confused with database.
- List converted without re-typing.
- Everything as free text.
Key takeaways
- A database = a table where each row is a page and each column is a typed property.
- Property types (date, select, number, relation…) determine what you can do with them.
- Views (Table, Kanban, Calendar, Gallery, Timeline) show the same data from several angles.
- Choosing the right types from the start determines filters, relations and automations.
48h challenge — apply it tomorrow
Create your «Projects» database (template above): 4 typed fields, 3 rows entered, one Kanban view by Status. 30 minutes is enough.
- I can explain row = page, column = typed property.
- I know why the type determines everything (filters, relations).
- I created my database + 2 views (Kanban, Calendar).
Frequently asked questions
What is the difference between a simple table and a Notion database?
A «block» table is static: text boxes, with no intelligence. A database is structured: each column has a type (date, number, select…), each row is a page you can open and enrich, and above all you can filter, sort, group and create several views. It is the difference between writing «Monday» in a box and having a real Date field on which you can filter «this week» or display a calendar. As soon as you want to exploit data (not just display it), you need a database.
Can I turn an existing list into a database?
Yes, but the cleanest approach is often to rebuild the structure as a database so the columns are well typed. Notion lets you insert a database and enter or paste your data there; you can also import a CSV. The key point is to think about the structure first: which properties, which types, which views? A bulleted list converted without reflection gives a poorly typed database that is hard to filter. Take five minutes to define your fields: that is what will make everything else (filters, relations, automations) possible and reliable.
What is the real power of Notion?