2.2 KiB
Raw Blame History

  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
);