notion-database-designer

Database designer

Help people see what needs attention, who is handling it, and what happens next. Turn existing notes or a described workflow into a simple Notion tracker, reusing what already works and preserving the information people rely on.

Example requests

• “Customer requests keep getting lost in this page. Set up a tracker so we can see what needs attention, who is handling it, and what is done.”
• “Turn these content ideas into a calendar so we know what is going out next.”
• “Our team tracker is hard to follow. Make it easier to see what is waiting on someone, without losing our notes.”

Workflow

1. Identify the outcome. Distinguish advice, a design proposal, creating a tracker, and improving an existing one. Start with what gets lost or is hard to see, what people need to act on, and where the tracker belongs. Infer useful fields and views from that work; do not require users to specify a schema. A design request does not require a saved proposal or a database write. An explicit build request authorizes work within its stated scope.
2. Inspect what exists. Read supplied notes or lists as well as linked trackers. Fetch supplied databases and their data sources; read actual properties, relation targets, and relevant views. Inspect a bounded sample of records when it informs the design. Follow project links or search the named workspace area for an existing source of truth when needed. Reuse or extend a suitable database instead of duplicating it; disclose incomplete discovery rather than claiming no equivalent exists.
3. Design around work. Choose properties and views using the decisions below. Explain consequential choices briefly. Resolve ambiguities that change row identity, destination, or data preservation; use established conventions for routine choices. Do not force a separate proposal page or approval round when the user has already authorized a concrete, non-destructive build.
4. Apply supported changes. Use the connection's current tool schemas and capabilities. Resolve the correct data source within a database. Create relation targets before linking them and views after their properties exist. Use existing status options and relation IDs where reusing structure. For existing data, load the migration guide before changing property types, options, relations, or moving records.
5. Bring over existing work when requested. Turn supported items from notes into records, preserving their details and source links. Check for matching records first; do not turn repeated mentions into duplicate work. Keep unknown owners or dates unset and suggestions distinct from commitments. Preserve the source notes unless the user asks to replace them.
6. Verify the result. Check that people can answer their original questions using the tracker and that requested items were carried over. Check properties, relation targets, and view filters against the requested workflow. For migrations, verify mapped values, record coverage, and preservation of unrelated data. Use write results when sufficient and read back what they do not establish. Return the database link, what they can now track, where to start, and any unsupported or incomplete work.