-
This commit is contained in:
parent
db85be0262
commit
3f40f6109d
@ -1,4 +1,5 @@
|
||||
# data_engineer_fasrpost
|
||||
|
||||
# Запуск
|
||||
```cp .env.example .env```
|
||||
```docker compose up -d```
|
32
tasks/1.md
32
tasks/1.md
@ -1,32 +0,0 @@
|
||||
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,
|
||||
datetime timestamp with time zone NOT NULL,
|
||||
action public.useractions NOT NULL,
|
||||
object_id integer,
|
||||
response smallint NOT NULL
|
||||
);
|
||||
```
|
Loading…
x
Reference in New Issue
Block a user