matv864/python_dev_ivanov_matvey
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update readme

Browse Source
This commit is contained in:
Ivanov Matvey 2025-03-14 16:16:55 +10:00
parent fadb41922a
commit e68c202208
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@ -46,5 +46,6 @@
сходить на дочерние таблицы, найти нужный тип (например event_type - login), взять от него id, прийти назад и создать запись с нужным id, при этом это ещё будет не надёжным (кто-то удалит тип, поменяет название, всё поляжет) + а зачем нам отдельная таблица? (я в том смысле, что над этими типа у нас есть все операции круд, но без изменения кода бэкенда - это либо бесполезно, либо опасно) сходить на дочерние таблицы, найти нужный тип (например event_type - login), взять от него id, прийти назад и создать запись с нужным id, при этом это ещё будет не надёжным (кто-то удалит тип, поменяет название, всё поляжет) + а зачем нам отдельная таблица? (я в том смысле, что над этими типа у нас есть все операции круд, но без изменения кода бэкенда - это либо бесполезно, либо опасно)
- я заменил на более удобные Enum - я заменил на более удобные Enum
- (не знаю успею ли я закончить формирование датасета comments после ответа на вопрос) - датасет comments
- в ТЗ было сказано, что мне нужно сделать датасет в котором должна быть информация о том, кто кому какой коммент оставил, хотя упоминание комментов было только в логах. Если бы мне такое попалось как реальное задание, то я бы пошёл к аналитикам, и стал настаивать на создании отдельной таблицы комментариев, где было бы указано - от кого, на какой пост, текст комментария - так как информации о связи постов комментариев не было - я создал таблицу Comment
- было упоминание в таблице логов, которую можно было дополнить столбцом, но мне кажется это не очень хорошим решением было сначала разделять на 2 БД, а потом пытаться связать данные внутри них