Notion database

Notion Database Designer

A well-modeled Notion database scales; a sloppy one becomes a junk drawer where the same project name is typed forty different ways and no filter works. The expensive mistake is deferred: free-text fields and duplicated names feel fine for a month, then the workspace crosses a few hundred rows and every view, count, and cleanup becomes manual archaeology.

Inputs to collect

1. What a single row represents, in one sentence (a task, a contact, a project). If a row could mean two different things, that is two databases - settle this first.
2. The questions people will ask of the data ("what's overdue?", "how loaded is each project?") - each question becomes a view or a rollup.
3. Who uses it and how often - each distinct audience gets its own view.
4. What already exists - related databases to link to rather than duplicate.

Operating procedure

Order matters: entity before properties (properties describe the entity), relations before rollups (rollups aggregate across relations), structure before views (views are lenses on structure).

Step 1: Define the entity

State in one sentence what a single row represents. If a row could mean two different things - a task sometimes, a meeting note other times - split into two databases now; migrating rows apart later is the most painful operation in Notion.

Step 2: Choose property types deliberately

Map each attribute to the right type. The governing rule: if you will ever filter, sort, or group by it, do NOT make it plain text.

• Select / Multi-select - fixed small sets (priority, tags). Prefer over free text so views and filters work.
• Status - workflow stages (To do / In progress / Done) with grouping built in; use it instead of a Select for anything that moves through states.
• Relation - links to rows in another database (Task → Project). The backbone of a real system; make it two-way so both sides see the link.
• Rollup - aggregates across a relation (count of tasks, sum of hours, latest date).
• Date - with reminders for deadlines.
• Person - owners and assignees; this is what powers "my tasks" views.
• Formula - computed fields (days until due, is-overdue flag).
• Text / Number / URL / Files - only when no structured type fits.

Step 3: Model relations, not duplication

Never type "Project Apollo" into every task row. Create a Projects database and relate tasks to it: rename the project once and it updates everywhere, rollups give project-level counts for free, and navigation works in both directions.

Decision rules for the three lookalikes:

• Relation vs. copied text: if two databases mention the same real-world thing, relate them. The test - would renaming it in one place need to propagate? Then it must be a relation.
• Rollup vs. formula: a rollup answers a question about related rows ("how many open tasks does this project have?"); a formula answers a question about this row's own properties ("is this task overdue?"). A formula cannot reach across a relation without a rollup feeding it, so if the input lives in another database, rollup first, formula on top if math is needed.
• Relation vs. select: if the options carry their own data (a client has an email, a tier, notes), it is an entity - use a relation to a database. If options are bare labels that will never hold data (priority: High/Med/Low), a select is correct and lighter. Promoting a select to a database later means re-linking every row by hand, so decide by asking whether the option will ever need properties of its own.

Common relation patterns: Tasks → Projects → Goals (cascading), Notes → People / Companies (CRM-style), Tasks ↔ Sprints.

Step 4: Build views for each audience

One database, many views - one view per question someone actually asks:

• Board grouped by Status - daily work.
• Calendar by due date - deadlines.
• Table filtered to "Assigned to me" + "Not done" - the personal queue.
• Gallery - when visuals matter (assets, contacts).

Each view = filter + sort + group + visible properties tuned to exactly one job. A view answering two questions answers neither well.

Step 5: Templates and defaults

Add database templates so new rows start pre-filled (standard checklist, default properties), and set default values on Status and Select properties. Every field an author must fill manually is a field that will eventually be left blank.

Worked artifact: a three-database schema

Client work tracker - Clients, Projects, Tasks:

CLIENTS
  Name (title) | Contact email (email) | Tier (select: A/B/C)
  Projects (relation → PROJECTS, two-way)
  Active projects (rollup: Projects → Status, count per group)

PROJECTS
  Name (title) | Status (status: Planned/Active/Done)
  Client (relation → CLIENTS, two-way)
  Tasks (relation → TASKS, two-way)
  Open tasks (rollup: Tasks → Status, count where not Done)
  Latest due date (rollup: Tasks → Due, latest)
  Due (date) | Owner (person)

TASKS
  Name (title) | Status (status) | Due (date) | Assignee (person)
  Project (relation → PROJECTS, two-way)
  Overdue? (formula: Due < now() and Status != Done)

Views: TASKS board by Status ("Daily work") · TASKS table Assignee=me +
Status!=Done ("My queue") · PROJECTS table sorted by Latest due date
("Project health") · TASKS calendar by Due ("Deadlines")

Why it is shaped this way: Tier is a select because A/B/C are bare labels; Client is a relation because clients carry email and tier; "Open tasks" is a rollup because it counts rows in another database; "Overdue?" is a formula because it reads only the task's own Due and Status.

Deliverable

Produce a schema sheet: each database with its one-sentence entity definition, every property with its type and a one-line reason, the relation map with rollups annotated, the view list (name, filter, sort, group, audience), and the row template contents for the common case.

Quality bar

• Every workflow field is a Status or Select, never text.
• Cross-database links use two-way Relations, never copied names.
• Rollups surface the aggregates someone actually reviews - no vanity counts.
• At least one view per distinct audience or question.
• A row template exists for the common case, with defaults set.
• Each database's entity fits in one sentence with no "or" in it.

Do NOT

• Do not build one giant database for everything - a row that can mean two things breaks every filter; split by entity type.
• Do not allow free-text statuses - "done", "Done ", and "DONE" are three values to a filter, and the views silently rot.
• Do not chain deep formulas nobody understands - keep formulas simple and add a description; an opaque formula becomes untouchable and then wrong.
• Do not add a rollup for every possible aggregate - each one costs load time and attention; roll up only what someone reviews.
• Do not model bare labels as databases - a Priority database with three childless rows is ceremony, not structure.

Related skills

For a full personal knowledge-management practice - capture habits, PARA-style organization, review cadence - use second-brain; this skill designs the databases such a system might sit on. Application and SQL schema design belongs to database-schema. If the database backs a team documentation library, pair with document-template-system for the row templates' content.