diff --git a/README.md b/README.md index f31b2d9..f2e67bd 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,5 @@ # data_engineer_fasrpost # Запуск -```docker compose up -d``` \ No newline at end of file +```cp .env.example .env``` +```docker compose up -d``` diff --git a/tasks/1.md b/tasks/1.md deleted file mode 100644 index 162ea0b..0000000 --- a/tasks/1.md +++ /dev/null @@ -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 -); -``` \ No newline at end of file diff --git a/tasks/2.md b/tasks/2.md deleted file mode 100644 index e69de29..0000000