Организация БД

mysql

Можно добавить еще один столбец в существующую таблицу, followers_prev или даже не один: followers_prev2, followers_prev3
При обновлении set followers_prev3=followers_prev2,followers_prev2=followers_prev,followers_prev=followers,followers="актуальные данные"
Если я правильно понял задачу

Мне тоже интересно, я так понимаю, что нужно будет каждый раз считывать данные подписчиков добавлять текущими и заменять предыдущее значение.
Не знаю как строятся запросы на обновление в mysql.

Как по мне, самый удобный вариант завести еще одну таблицу.
Создавать несколько одинаковых полей слегка криво, в таком варианте лучше завести одно поле и хранить там JSON.

Во всех вопросах, где нужно решить каким образом хранить данные (какую структуру или способ выбрать) - всегда забывают об одном очень важном моменте: а что вы с этими данными будете затем делать?
Для чего вам хранить такого рода историю? Как вы будете с ними в дальнейшем работать: визуализировать их или делать какие-то расчеты, на основе того, что имеете?
Следует идти "с конца" и думать о конечном использовании - тогда сразу станет понятно какие из способов можно сразу же отбраковать (например, для визуализации скорее всего будет крайне неудобно хранить всё в JSON, т.к. в конечном итоге он разрастется до того, что будет тормозить весь парсинг из-за него + удаление / изменение - это сложно с точки зрения реализации и времени для выполнения).

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

Если СУБД использовать сложно, то другим крайне простым (но не очень хорошим / удобным для реализации) вариантом будет использование отдельной таблицы для каждого аккаунта с историей изменения подписчиков. То есть имеем 1 файл-таблицу с аккаунтами (и то можно пренебречь ей, если по сути для аккаунта нужно хранить только логин без другой информации) и множество файлов-таблиц, которые именем файла (например) связаны с логином и внутри содержат количество подписчиков на определенную дату.

@Lord_Alfred +1, для начала надо понять для чего эти данные, как они будут использоваться.
Насчет Json, ИМХО это верх кривизны. Ни поиск, ни сортировка данных, вообще ничто не будет доступно, пока не прочтешь ВСЕ поля Json и их не распарсишь.
А если не нужен поиск, сортировка и т.д., то какой вообще смысл хранить эти данные в БД?

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

Для примера хочу такую статистику по каждому объекту

стат: время
стат: время
стат: время

Дабы потом отследить динамику изменения статистики во времени.

Подойдёт ли json или как лучше это организовать в mysql?

Не люблю джейсон, можно сказать даже презираю, вместе с иксемель