cron + grep ?

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

Вопрос к знатокам баз данных:

Имеется таблица из названия (TEXT) и максимального количества (INTEGER).
Нужно следить за прогрессом заполнения максимального количества каждого строки.

Условно.


TITLE | MAX_COUNT
— | —
A | 100
B | 23


И нужно где-то следить за заполнением A и B (и остальных строк, если они появляются).

Вижу два варианта:

1) Добавить в эту же таблицу столбец Progress и вести подсчеты там.

2) Добавить новую таблицу с прогрессом, в которую будут отдельными строками прилетать прогресс и к чему он относится.

Второй вариант кажется приятнее, т.к. имеется возможность следить за прогрессом куда более подробно, добавить доп. поля для каждого обновления, но что-то внутри меня подсказывает, что это будет дюж тяжело для устройств/серверов, собирать данные для каждой строки каждый раз.

Что если будет миллион объектов на сто тысяч пользователей? Каждый раз придется собирать все данные из исходной таблицы касающиеся этого пользователя, потом по этим данным собирать весь прогресс (которого уже явно куда больше миллиона) касающийся этих данных. Звучит жутко.

Может кто-нибудь развеить страхи или же подсказать более удачный вариант?

+ в идеале, чтобы решение было действительно рабочим как с SQL так и с NoSQL, либо же с какими-то плюсами/минусами, ибо пока нет ясности с каким вариантом работать.

ну вот надёргал примитив там сям (надо поправить под ваш SMTP)

непонятно что значит "Нужно следить за прогрессом заполнения максимального количества каждого строки."

В примере вот есть строка A 100.
Объект A, у которого максимальное значение 100.

Изначально 0 из 100.

Прогресс идет как получится. Сейчас может добавиться 1, завтра 10, послезавтра ничего, а потом сразу 40. И так пока не заполнится до этих самых ста.

Еще не понимаю чем "следить" отличается от "сделать запрос к БД". Если нужно сделать какой-то запрос, значит его нужно сделать.

Речь о том, как лучше организовать такую БД.
Оставить поле прогресса в изначальной таблице и изменять это поле там, или же завести другую таблицу для прогресса.

UPDATE вообще дорогое удовольствие. А как долго длится процесс, за прогрессом которого нужно следить? И как часто этот UPDATE будет делаться? И с какой целью это делается? Для пользователя или для аналитики?

UPDATE делается самими же пользователями. Может хоть 20 за день, хоть 0. От пользователя.

Делается с целью ведения статистики для пользователей.
Аналитика больше как бонус идет.

Т.е. сама суть этого как раз для того, чтобы пользователь следил за прогрессом.

ну тогда это обычное редактируемое поле. не вижу смысла тут что-то мудрить. в той таблице к сущности которой прогресс относится там и хранить.

Да, но так оно совсем не гибкое. Нет возможсности узнать, сколько и когда прогресса было сделано. Это серьезный минус.

Ну если очень надо, то отдельная таблица для хранения всей истории всех прогрессов. И для получения текущего прогресса.. будет более сложный запрос с агрегированием всей истории изменений прогресса. Это утяжеляет SELECT, конечно.

Да. И вот интересно, насколько такой подход вообще юзабелен. Делают ли так? Не задохнется ли сервер от такого кол-ва запросов?

Это не bad practice. Наоборот, если такая гибкость нужна, то значит надо делать так. Это нормализация БД. И следование паттерну "сага".
Можно кэшировать последние значение в основной таблице (со всеми вытекающими плюсами и минусами кэширования...). не айс, потомучто дублирование.
Промежуточный вариант, это просто писать историю в виде json'a в одно поле, рядом с полем текущего значения прогресса. Тоже не айс.. но где-то может сгадиться.