Start with the smallest useful structure
Do not add more fields, categories, or granularity than the workflow actually needs. The smallest useful structure is often easier to maintain, easier to review, and easier to map into models later.Keep raw and modeled logic separate
Use the database to store records, source values, and row-level logic that belongs to the data itself. Use the model for:- planning assumptions
- scenario logic
- business rules that span several records
- outputs designed for decision-making
Use stable names and clear field meaning
A database becomes harder to trust when field names drift or a single column starts carrying several meanings. Prefer:- business-readable field names
- one clear meaning per column
- clean date and category fields when they matter downstream
- controlled structural changes instead of ad hoc edits
Govern change like shared infrastructure
If several models or boards depend on the same database, manage changes carefully. Review schema changes before you:- rename important fields
- remove columns
- change category meanings
- alter the effective grain of the dataset
Make sync ownership explicit
Every important database should have a clear owner for:- refresh timing
- source query review
- connection issues
- downstream change communication
Retire stale databases deliberately
Unused or outdated databases create risk when teams assume they are still current. Archive or retire stale datasets deliberately so people do not build new work on top of old records.Before you rely on a database broadly
Use this checklist before you publish or reuse a database widely:- confirm the structure matches the intended workflow
- confirm the grain is clear
- confirm key fields are typed and named clearly
- confirm refresh ownership is clear
- confirm linked models, boards, or mappings still behave as expected