1. Спроектировать схему БД я здесь вижу 2 варианта развития 1) сделать одну таблицу в которой будет: - id пользователя - время выполненного дйствия - enum из различный действия (бэку не нужно лишний раз искать id действия, чтобы закрепить его в таблице логов) - (отдельная таблица для действий будет лишней) - (бэку необходимо знать и контролировать все действия, а таблица будет лишь означать изменение данных извне, которое будет либо бесполезной, либо опасной, когда бэк не найдёт нужное действие) 2) разбить на несколько таблиц: - таблица логов аккаунта - таблица работы с темой - таблица работы с сообщениями - 1 вариант - 1) ускоренная разработка из-за отсутсвия необходимости задумываться над подтягиванием данных из других таблиц (join, lazy_loading, selectin) 2) простота работы с данными: SQL запросы намного проще, более удобный перенос в csv - 2 вариант - 1) БД более подготовлена к изменению или усложенению архитектуры 2) повышение эффективности за счёт меньшего количества столбцов в ТЗ не было речи про дальнейшую судьбу этой БД, так что я пойду на 1 вариант ``` CREATE TABLE public.log ( id integer NOT NULL, user_id integer NOT NULL, action public.user_actions NOT NULL, datetime timestamp with time zone DEFAULT (now() AT TIME ZONE 'EAST'::text) NOT NULL, object_id integer, response smallint NOT NULL ); ```