How to design a base for a note taking app?

Question

Database design

Good afternoon everyone! I saw (more precisely, I made) a small note-taking application for myself. The essence is simple - there is a form through which fields are saved in one table on the backend: category, section, tag, picture, note, date ... Notes are added, and then rendered by react.
All this is wonderful, but I wondered "what if there are a million notes? Will the whole thing slow down?". Now, in fact, the entire table from the database flies to the browser and then the necessary data is rendered in different places. Therefore, I appeal to the participants of this chat with a question about the architecture of such a simple application. How to do it right? Do I need to spread information across different tables - the main one: id-note, a table with a list of categories, a table with a list of sections, a table with a list of tags...? How to use the browser's localStorage as much as possible (there is an assumption that it is better to save the global state of the application there or in indexedDB and synchronize it with the backend from there)? I would be glad to hear any opinions - polite and not very.

Answer 1

Will this whole thing slow down? - will not become
- whether it is necessary to carry the information on different tables? - need. Plus tables-links, "note-section", "note-tag". But first you need to decide how the section differs from the category.
- How to make the most of localStorage? - no way

Answer 2

Purely offhand:

Tags
    -tag_id:int
    -tag:char/varchar
Cagegories
    -category_id:int
    -category:char/varchar
Notes:
    -note_id:int
    -note:text
    -created_at:datatime
    -updated_at:datetime
    -category:FK->Cagegories
Notes_tag:
    note:FK->Notes
    tag:FK->Tags

The request scheme is approximately the following (very conditional, purely to show the principle):

select *.n, category.c, from Notes n, Cagegories c
join JSON_ARRAYAGG (запрос к Notes_tag)
order by created_at desc
limit [from] [to]

upd:
When requesting, dynamically substitute values ​​in [from] [to]
JSON_ARRAYAGG join example (found on the internet)
https://www.db-fiddle.com/f/mUJLe4gPw9CZyLcfS3wrMY/0

Answer 3

If the entire table from the database arrives at the browser, and then the browser deals with this million, this is wrong.
The browser sends a request like "give me notes with such and such tags, 50 pieces", "give me notes for February, page 3, 50 pieces", etc. And the server understands and builds a query in the database. With a normal API, you will be able to change the data structure in the database without having to redo the client.
Now, it may not make sense to spread all the data into different tables: categories, tags, etc. At a scale of up to a million rows, a normal DBMS will shovel one table at quite a decent speed, in the "application for yourself" mode you will hardly notice the brakes. Dividing data into separate tables gives:
a) simplification of managing all this (for example, getting a list of categories or a list of tags,
b) experience of similar database normalization.
But in general, in order to use such an application for personal purposes, this is not necessary.