Note Table Design in MySQL for SmartNote
A focused design note on the note table structure, indexing strategy, and soft-delete decisions.
The note table is the center of SmartNote, so I designed it for both current features and next-step expansion.
Core fields#
id: primary keyuser_id: owner referencetitle: note titlecontent: body contentis_deleted: soft-delete flagcreate_time,update_time: timestamps
Why soft delete#
Soft delete protects data recovery and auditability. It is useful when users delete by mistake or when features like restore/trash are added later.
Indexing direction#
At minimum:
- index on
user_id - index on
(user_id, update_time)for personal lists
When search expands, move keyword handling to dedicated search strategy instead of overloading basic indexes.
API implications#
With this table, the service layer can support:
- create note
- update note
- list notes by user
- soft delete note
- later: favorites and recommendation signals
Closing#
Good schema design is not about complexity. It is about predictable evolution. A clear note table keeps the rest of the backend easier to implement and explain.
Related posts
View allSmartNote Database Design from user and note to note_tag
A practical walkthrough of SmartNote core tables, relationships, and why each design choice helps later backend work.
Why Redis List Works Well for Search History in SmartNote
Practical reasons for using Redis List for recent search history, with key design and operation strategy.
Why I Chose SmartNote as My Java Backend Practice Project
Why I moved away from generic template projects and started building a knowledge-focused backend project I can keep iterating.