Comments 14
Забавно: я database performance guru (MSSQL). После известных событий 2022 года искал новую работу. Техническое интервью. Первый вопрос: какие нормальные формы вы знаете?
Я много проводил нормализаций и денормализаций, но честно признался что ни разу в жизни названия этих форм мне и не пригодились
Смысл, наверное, не в названиях. А в существе дела. Существо-то Вы, наверное, не забывали никогда.
Так и есть. Тоже всегда больше “на интуицию” нормализовал, чем по правилам. Но со временем понимаешь, что интуиция — это по сути и есть усвоенные те самые формы, просто без зазубривания названий. Как только начинаешь серьёзно работать с реляционками, оно само приходит.
Как-то много всего. На входе говорили про быстрый старт, отсюда простой вопрос, может ли Mongodb все то, что может Postgresql, и, соответственно, наоборот. Поэтому выбирается Postgresql, вместо двух БД или той БД, которая не сможет покрыть отчёты, при необходимости. JSONB - тема, там где нет ясности по структуре. Mongodb - наверно больше оптимизация, но в таких случаях, вроде, все больше берут cassandra или scylla, есть ощущение, что Mongodb берут все реже.
Нет примерно никаких ситуаций, чтобы использование Mongo было оправдано. Начиная с лицензии и заканчивая ее техническими проблемами (тормоза, неэффективная и хрупкая репликация)
За мой пятилетний опыт работы с Mongo в проде особых сложностей не было. Под нагрузки на запись и иммутабельные агрегаты ложится идеально. Self-hosted Community Edition не требует лицензии, а репликация в свежих версиях с настройкой write concern и majority вполне достаточная для большинства кейсов. Ну и описанный в посте кейс с чеками считаю удачным примером использования Mongo.
Всё действительно упирается в специфику задачи. Если нагрузок и особых требований нет, можно хоть в файле хранить данные и обернуть это тонким слоем доступа.
В реальных же проектах Mongo чаще используется как нишевый инструмент. Она хорошо чувствует себя там, где write-heavy поток и иммутабельные агрегаты (чеки, телеметрия, события), и где нужна простая масштабируемость. Но как “универсальная база для всего” её сейчас берут всё реже — чаще выбирают Postgres с JSONB
Все б хорошо если б монга не была такой тормозной и неэффективной по памяти/хранилищу
Да, безусловно можно "по быстрому стартануть" сложив все как есть куда-то, а потом, когда начнется сопровождение и развитие получить максимальное "удовольствие" от принятого решения на старте.
Как по мне, база, являющаяся хранилищем данных, есть часть фундамента приложения. А значит ее выбор и проектирование структуры данных важно. Я не за то, чтобы рьяно до буквы соблюдать все 7 нормальных форм, или даже хотя-бы первые три. В конце концов они носят рекомендательный характер. Но ты должен понимать ответственность за нарушение этих норм (об этом Вы тоже говорили) и уметь при необходимости нивелировать эти последствия, используя инструменты в базе, а в том-же Postgres такие инструменты есть. А все-ли стартаперы понимают последствия? Опасно прикрываясь идеями о свободном мышлении выбирать простой путь в начале пути.
PS И кстати говоря, даже если ты в Postgres не все сделал по "правилам", то в последствии базу можно подправить, причем даже так, что приложение трогать не придется.
Я ни разу не гуру, но мне всегда казалось, что базово всегда надо делать sql и нормализации. А не надо только в том случае, когда формат данных может сильно меняться со временем по составу и структуре полей, причем надо поддерживать все варианты - и старые, и новые. Вот в такой ситуации да, монго или аналоги уменьшат боль(но не уберут полностью). А если данные просто сложные(пардон за), но более-менее одни и те же по структуре - ну потрать время на нормальную структуру табличек:)
Потому, что не надо выбирать базу данных для хранения логов, по сути. Зачем вообще какието базы, храните тупо в файлах.
Становится сложно делать быстрые выборки «всё про заказ целиком» — приходится собирать агрегат из кусочков.
Для того чтобы получить полный справочный «профиль» компании, надо тащить join-ы по десяткам таблиц или руками собирать агрегат.
А "Предстваления" или "Материализованные представления (persistent view)" разве не закрывают эти "проблемы избыточной нормализации"?
Типа если чересчур на-нормализировал - так сдклай виртуальную табличку, которая будет скрывать всю кухню. Зато рано или поздно - нормализация где-то да спасёт.
Представления и материализованные представления помогают, но всё равно не закрывают проблему “нормализации ради нормализации”. Получается почти как с преждевременной оптимизацией: где-то нормализация может спасти, а где-то — вообще не понадобится.
Кейс с 160 таблицами у меня как раз очень показательный. Там даже если сверху накидать ещё десяток представлений, суть не меняется — разработчики просто усложнили жизнь себе и всем остальным. Поэтому шаг вправо-влево допустим: не обязательно нормализовать всё “потому что так надо”.
Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь