Нормализация БД. Зло или добро?

Question

[Anton]

Добрый день!

Недавно смотрел интересную презентацию человека, который реализовал свой стартап до полноценного проекта. В этом проекте он использовал БД Postgres. Все конечно было интересно, но он сказал одну вещь, которая меня шокировала. Он сказал так: "Нормализация это зло! В некоторых случаях (этот процент небольшой) и при необходимости используйте нормализацию БД." Я никогда еще не делал проекты связанные с запросом данных в БД или вообще работой с БД, но проходил теорию по данному вопросу (в университете). И у меня возник вполне резонный вопрос: действительно ли нормализация БД является не лучшим союзником в реализации своего проекта (программы)?

Comments

[Валерий Рябошапко]

То есть человек вот так вот опроверг сходу прописную истину и никак это не аргументировал?

[Anton]

Он аргументировал. Он начал рассказывать о том, как НФ (нормальные формы) существуют, как к ним придти. И он сказал, что привел свои данные в БД к 5НФ. И программа спокойно работала с данными. Но потом как данных становилось все больше он заметил существенное торможение своей программы. И как он сказал, привел свою БД в 2 НФ и у него все стало работать очень быстро по сравнению с тем что было. И дал еще совет, МАКСИМУМ нужно доводить до 4 НФ, да и то не всегда.

[Валерий Рябошапко]

Антон: ну, собственно, вот и ответ на Ваш вопрос :-)

[mib]

нормализация данных ведет к экономии места - это хорошо,
но так-же ведет и к усложнению запросов джойнами и к увеличению времени обработки запросов, ведь каждый джойн - это вложенный цикл

[Валерий Рябошапко]

mib: старая как мир борьба между скоростью и объёмом :-)

Answer 1

[Артем Воронов]

Сильно зависит от масштаба проекта. Не стоит бросаться из крайности в крайность.
Для мелких проектов нормализация делает работу проще.
Но когда речь идет об огромных объемах данных и высокой частотой запросов, нормализация становится врагом. Даже простые JOIN увеличивают время выполнения запросов на порядок. Поэтому денормализация БД, внесение избыточности - обычная практика для HiLoad.

Answer 2

[pi314]

Нормализация ради нормализации - зло в подавляющем большинстве случаев! Нормализация, как часть продуманного проектирования или рефакторинга модели данных - однозначно добро. Структура БД должна быть, по возможности, оптимальной для запросов, выполняемых на ней приложением, а вовсе не соответствовать какой-то там нормальной форме :) Это "оптимально" может в каждом конкретном случае зависеть от кучи факторов, начиная от самих запросов и особенностей конкретной использованной СУБД, и вплоть до объемов доступной памяти и скорости обращения к диску.

Answer 3

[Therapyx]

По мне так - везде найдется тот, кто будет критиковать даже самый лучше вещи в мире.
И вот это видимо и есть такой случай. Ниразу не видел, чтобы нормализацию выставляли в плохом свете. Конечно, если ваш проект, программа на столько маленькая, что можно обойтись и без нормализации и при этом останется такое же удобство, быстродейственность, то это да - нормализация мб и не нужна. Но у проектов есть чудесное свойство, а именно развиваться :) И вот лучше такие вещи продумывать заранее, ежели потом держаться за голову.

Comments

[entermix]

Иногда, как раз после того, как проект вырос и приходится делать денормализацию))

[Therapyx]

entermix: это в каких еще таких случаях? )

[entermix]

Therapyx: В тех случаях, когда на БД производится высокая нагрузка при выборке данных, почитайте ответы других пользователей, там уже писали про это )

[coodan]

entermix: довольно грубое решение.

Answer 4

[Сергей Протько]

Все зависит от контекста высказывания (задачи разные бывают). Бросаться в крайности это глупо (только ситхи все возводят в абсолют (с) Оби)

Нормализация это не зло, нормализация это замечательно, но на больших нагрузках частенько приходится производить денормализацию. Опять же обычно это не значит что данные мы в нормальной форме больше не храним, просто мы попутно формируем и агрегации денормализованных данных для ускорения выборки.

p.s. уточните о чем был проект или скиньте ссылку, любопытно посмотреть на безумца или понять его хотя бы.

Answer 5

[Станислав Макаров]

Видите ли в чем дело - нормализация это не столько для СУБД и не для приложения ее использующего. Это больше для вас, для разработчика (БД и/или приложения), и для целостности и согласованности данных.

Безусловно, в продакшене идеальна та БД, структура которой позволяет выполнить наиболее частые (или тяжелые) запросы к БД максимально экономно с точки зрения аппаратных ресурсов (меньше чтений блоков с диска, меньше джоинов, наиболее эффективное использование индексов), и такая структура вовсе не обязательно должна быть в высокой нормальной форме. Однако, есть и другой вопрос - какая БД идеальна для вас, как для разработчика? Избыточность в базе - потенциал для ошибок. Если какую-либо информацию нужно обновить в двух местах (например, цену товара в чеке и общую стоимость заказа) - вы всегда имеете возможность где-то забыть это сделать.

Именно по причине несовпадения двух структур БД: максимально нормализованной, удобной для разработчика/проектировщика, и оптимизированной для выполнения запросов - стандартный цикл проектирования БД включает в себя этап нормализации до опредленного уровня (хотя бы до 3нф), и последующей денормализации для ускорения конкретных запросов (также, как и построение необходимых индексов). Т.к. денормализация требует усложнения логики работы с базой (те самые обновления в нескольких местах), эту логику (чаще всего это хранимки или триггеры, реже - на стороне приложения) нужно реализовывать максимально аккуратно и формально. Это похоже на написание кода на высокоуровневом языке и последующая его компиляция под конкретную платформу с максимальными оптимизациями. Единственное важное отличие - особенности целевой платформы известны заранее, и компилятор, учитывающий эти особенности, можно написать один раз, а вот особенности работы БД в каждой задаче - свои, поэтому в каждом случае нужно проводить работу по оптимизации БД с нуля.

Нужно отметить, что в современных системах денормализация схемы - не единственный и не всегда лучший способ повышения производительности. Кэширование часто используемых данных в каком-нибудь memcached - иногда проще и эффективнее, чем денормализация БД и поддержка ее согласованности.

Answer 6

[Максим Корюков]

Давайте разбираться.

В нормализованной бд (в общем случае) выборка по произвольным параметрам будет работать пошустрее. Проще добавлять и изменять данные.
Ненормализованная может дать очень большой выигрыш для четко очерченного круга запросов по выборке данных (не нужны лишние джойны, уже готова сортировка и прочее). Но если вам понадобится что-то нестандартное - готовьтесь к любому исходу. Скорей всего запрос будет работать очень медленно.

В нормализованной БД, запрос до определенной степени можно оптимизировать. Я видел, как хранимая процедура (очень большая) ускорялась с 2 часов до 5 минут с помощью подходящих индексов и правильных джонов, но оптимизацию проводил SQL-кунг-фу сэнсэй, он знал, что покрутить.
В денормализованной - вы так уже не сделаете, придется менять структуру данных.

Я бы старался нормализовать данные, но не до академического фанатизма, а до той степени, когда таблицы не вызывают отвращения ни у меня, ни у оптимизатора запросов используемой СУБД.

Answer 7

[coodan]

Согласен. Очень плохая практика, и ее рост ничего не доказывает.

Чай, не в каменном веке живем и есть уйма способов повышения производительности - от кэширования и до предварительной аггрегации данных. Но никакое повышение производительности не стоит нарушения целостности данных. К чему производительнее выдавать мусор?

Чувак просто слышал звон, да не знает где он. Взял мощную СУБД, а освоить мозгов не хватило. Вот и хвастается теперь своим невежеством, полагая, что он самый умный, а остальные дураки все.

Answer 8

[Йцу Йцуевич]

Если у тебя ещё нет опыта работы, то сделай чтобы он появился.
А то сейчас ты можешь сделать преждевременный вывод, и возможно он будет ошибочным.

А на счёт зло добро, не знаю...
ИМХО, смотря до какой степени проводить нормализацию