32 lines
2.1 KiB
Markdown
Raw Normal View History

2025-03-14 03:44:10 +10:00
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,
2025-03-14 04:22:14 +10:00
datetime timestamp with time zone NOT NULL,
action public.useractions NOT NULL,
2025-03-14 03:44:10 +10:00
object_id integer,
response smallint NOT NULL
);
```