Как спроектировать базу для приложения заметочника?

Question

[kiberlain]

Всем добрый день! Пилю (точнее сделал) для себя маленькое приложение-заметочник. Суть проста - есть форма через которую в одну таблицу на бэкенде сохраняются поля: категория, раздел, тэг, картинка, заметка, дата... Заметки добавляются, а потом рендерятся реактом.
Всё это замечательно, но я задался вопросом "что если заметок наберётся миллион? не станет ли всё это дело тормозить?". У меня сейчас по сути вся таблица из базы прилетает в браузер и потом нужные данные рендерятся в разных местах. Поэтому обращаюсь к участникам этого чатека с вопросом по архитектуре такого простецкого приложения. Как сделать правильно? Нужно ли разносить информацию по разным таблицам - основная: id-note, таблица со списком категорий, таблица со списком разделов, таблица со списком тэгов...? Как максимально задействовать localStorage браузера (есть предположение что глобальное состояние приложения лучше там сохранять или в indexedDB и оттуда синхронизировать с бекендом)? Буду рад услышать любые мнения - вежливые и не очень.

Comments

[Дмитрий]

Разнести конечно, удобно будет например добавлять категории или теги. Выборку всего делать не обязательно, есть же дата ну и прочие фильтры можно сделать

[Дмитрий]

Ну и миллион записей для бд это семечки, вот фронт может сдохнуть

[kiberlain]

Дмитрий, в том то и дело, вот и подумал как облегчить жизнь фронту и бэку)

[Дмитрий]

kiberlain, да бэк и так почти в холостую работает, не думаю, что там заметки добавляются пачками. Фронту тоже все не нужно отдавать, экран же не резиновый

Answer 1

[FanatPHP]

- не станет ли всё это дело тормозить? - не станет
- нужно ли разносить информацию по разным таблицам? - нужно. Плюс таблицы-связки, "заметка-раздел", "заметка-тег". Но сначала надо определиться, чем отличается раздел от категории.
- Как максимально задействовать localStorage? - никак

Answer 2

[Александр Нестеров]

Чисто навскидку:

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

Схема запроса примерно следующая (очень условная, чисто показать принцип):

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

upd:
При запросе динамически подставлять значения в [from] [to]
Пример join`а JSON_ARRAYAGG (нашел в инете)
https://www.db-fiddle.com/f/mUJLe4gPw9CZyLcfS3wrMY/0

Comments

[FanatPHP]

ОМГ, ну и дичь
что ж вам всем неймется везде этот жсон всунуть?
а потом прибегать и сопли размазывать "ой у миня фсё тармазиииииит!"

ой, самое-то прекрасное я сразу не заметил. джойн - это пять.
то есть наша макака код написала, но что он значит - даже близко не поняла :)

[FanatPHP]

зачем char?
тоже слышал звон да не знаешь где он, решил написать все умные слова, какие "в интернете нашел"?

Answer 3

[Михаил]

Если вся таблица из БД прилетает в браузер, а затем браузер с этим миллионом разбирается - это неправильно.
Браузер шлет запрос, типа "дай мне заметки с такими-то тегами, 50 штук", "дай мне заметки за февраль, 3 страница, 50 штук" и т.п. А сервер разбирается и строит запрос в БД. При нормальном АПИ вы сможете менять структуру данных в БД без необходимости переделывать клиент.

Сейчас, возможно и нет смысла разносить все данные по разным таблицам: категории, теги и пр. На масштабах до миллиона строк нормальная СУБД перелопатит одну таблицу со вполне приличной скоростью, в режиме "приложение для себя" вы вряд ли заметите тормоза. Разнесение данных по отдельным таблицам дает:
а) упрощение управления всем этим (например получить список категорий или список тегов, переименовать тег и т.п.)
б) опыт подобной нормализации БД.

Но в целом, для того чтобы пользоваться подобным приложением в личных целях это необязательно.