SQLite: как лучше оптимизировать таблицу (и нужно ли вообще)?

Допустим, есть что-то типа ежедневника, куда пользователь регулярно делает записи. Он делит эти записи на категории, например: «дела», «покупки», «контакты» и т. д., ну как ему удобно, так и делит, он решает это сам. Может вообще все в одну категорию записывать. Этот «ежедневник» представлен в виде сайта, пользователь кликает на нужную категорию, ему на страницу подгружаются соответствующие записи, он может их редактировать, удалять или добавить новые.

Короче, мы создаем что-то вроде CMS.

Технически это выглядит так: на сервере есть база данных sqlite с таблицей, куда заносятся все записи пользователя. В таблице несколько колонок, ну например:

id записи | название | текст | дата создания | категория

Соответственно, необходимо будет проводить следующие операции: добавление записи, редактирование, удаление, поиск записей по категории и по id. Самой популярной операцией предполагается поиск (но это только гипотеза).

Размер одной записи может варьироваться от самых минимальных значений (несколько символов просто) до 150-200 кб данных.

Количество таких строк тоже может быть очень разным, от нескольких десятков до нескольких тысяч. Давайте, например, решим, что максимум он может внести 10.000 строк. При этом максимальный размер базы будет ограничен 500 мб, так что он не может внести 10.000 строк по 200кб, к примеру.

Запросы к БД будут делаться не очень часто. Ну, скажем так, с человеческой скоростью, то есть не будет 1000 запросов в секунду. Вот как пользователь ходит по сайту, нажал кнопку категории = запрос, отредактировал что-то, отправил изменения = запрос. Может где-то будет несколько запросов подряд, но не больше.

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

Так вот, мы имеем 2 предельных варианта: 1 — пользователь внес одну минимальную запись; 2 — пользователь внес 10.000 записей и занял 500мб.

Да, на практике скорее всего будет что-то среднее, но надо, чтобы обе эти ситуации отрабатывались. И если с 1 проблем не возникает, то вот 2 вызывает вопросы.

Я понимаю, что вроде как 500мб и 10.000 строк это ну не настолько прямо много, да и сложные операции с данными не планируются. С другой стороны, я не совсем понимаю, что значит «много», и с каких значений могут начаться проблемы с производительностью, если учесть, что запросы к БД формируются корректно, чтобы обойтись без лишних обращений.

Очевидно, что вопрос производительности зависит от вычислительной мощности, и на суперкомпьютере гугла все это будет происходить незаметно, а на ЭВМ мохнатого года - нет. Поэтому вопрос больше в том, будет ли толк от вообще какой-либо оптимизации такой базы данных?

Я вижу 3 возможных варианта:

1. Забить на оптимизацию. Просто оставить как есть, пусть будет таблица, 10.000 записей, 500мб, совершать запросы прямо в лоб, без изобретения велосипедов. Отчасти я склоняюсь к этому варианту.

2. Попробовать поработать с индексами. Но индексировать тут как будто и нечего, сложные запросы я не делаю, а если проиндексировать категории, например, то боюсь, что только хуже будет.

3. Разделить таблицу на несколько небольших. Вот над этим вариантом думаю больше всего. Сделать отдельную таблицу под каждую категорию. С одной стороны, это не совсем логично, потому что все записи по идее имеют 1 сущность, и правильнее держать их в 1 таблице. Более того, это местами усложняет код, появляется дополнительная ниша для возникновения ошибок. С другой стороны, мне по сути никогда не надо обращаться к таблице целиком. Обращение идет либо по категориям, либо по id, но с учетом, что категория записи уже известна. Так что, если я разбиваю таблицу таким образом, то не теряю в функционале, но получаю гибкость оптимизации. То есть, теперь, если какая-то категория начинает тормозить, пользователь просто может создать другую = создать новую таблицу в БД. А поскольку мы решили, что пользователь в этой базе 1, то вряд ли есть опасность замусорить ее кучей таблиц.

Так что вот, вопрос в оптимизации БД. Что стоит предпринимать в описанной ситуации?

Ну и вообще концептуально о пределах, когда об этой оптимизации стоит задумываться? Потому что очевидно, что если в таблице 1 запись, то оптимизировать нечего. А если 10? А если 100, 1000, 10000… Есть ли какие-то общепринятые признаки того, что стоит задуматься об оптимизации? Ну кроме того, что БД уже тормозит, чтобы предвидеть ситуацию.