Всем привет, меня зовут Антон. Я тимлид продукта Setezor - сетевого сканера с уклоном развития в ПО для проведения пентеста. Хочу рассказать об опыте проектирования БД, а именно использования нормализации, которой меня так рьяно учили в универе. При старте продукта в качестве прототипа для хранения информации о результате сетевых проверок было решено использовать модель представления сетевого взаимодействия OSI. С точки зрения теории выбранная модель с лихвой покрывала потребности и соответствовала канонам уровней нормализации данных в БД. 7 вложенных уровней, каждый является зависим от предыдущего и описывает только свою абстракцию. Красота.... Когда дошло до дела использовать такую схему оказалось слегка неудобно: - 7 уровней вложенности - это ад для JOIN-ов - возникли некоторые "интересные" ситуации реальной работы сетей, которые не сходятся с теорией - с учётом использования ORM SQLAlchemy привязать цепочку объектов к другому родительскому объекту оказалось не так-то просто - проверка на существование записи в БД стала сводить с ума, т.к. проверка объекта стала зависеть от того, кто его родитель Почему ни в универе, ни на работе никто не говорил, что проектирование БД - это не про красоту и правильность, а про удобство использования и соответствие процессам, которые автоматизирует твой код. - Есть дубликация данных? Ну и пусть будет, если тебе так удобно. - Если тебе проще дополнительно в таблице хранить имя пользователя текстом без ссылок на другие таблицы или запросы в другие сервисы, то храни и одним запросом без сложных конструкций получи данные и отдай на фронт. - Если тебе удобно держать всё в одной таблице, а дополнительные данные толкнуть json-ом в отдельное поле, то делай как это будет удобно тебе. Конечно стоит задуматься об оптимизации работы БД и рациональном использовании диского пространства, но от пары, даже пары десятков потраченных Гб ничего не изменится, а "правильно" спроектированная БД будет добивать вас и вашу команду ещё долго. Так о чем это я. Не стоит слепо верить авторитарному мнению. Лучше скептически подойти к чужому опыту, перенести его на свои плечи и посмотреть, как это решит вашу проблему, а не проблему автора. Потому что "дьявол кроется в деталях".