Привет Хабр! В прошлой статье мы детально разобрали функциональные зависимости. Возможно, после нее у вас, как и у многих, остался закономерный вопрос: зачем нам вообще так париться, выискивая эти зависимости? Как это применяется в проектировании баз данных?

Естественно, можно спроектировать базу данных, вообще не заботясь ни о каких правилах. И она даже будет работать! Все будет прекрасно ровно до первого ее реального использования в продакшене. При проектировании «абы-как» возникают три типовые проблемы: избыточность, аномалии обновления, аномалии удаления.

И вот это уже плохо.

Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.

Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.

За долгий период существования IT в прод уходила не одна тысяча багов. Большинство из них были безобидными и исчезали после следующего патча. Но отдельные приводили к катастрофам. Буквально. Анализируя тему крупных техногенных провалов, я удивился одному: за большинством этих инцидентов стояли не сложные цепочки событий, а маленькие, пустяковые на первый взгляд детали. Вот тут что-то забыли дописать, тут понадеялись, что пронесет, там решили что «и так сойдет». А итог — многомиллионные убытки, удар по репутации и потерянные жизни.

Рассмотрим на примерах, почему не стоит недооценивать баги.