Как стать автором
Обновить

Комментарии 22

При проектировании структуры БД я руководствуюсь принципом: «Если нет положительного опыта конкретной денормализации, то используй третью нормальную форму (как минимум)». В последующем легче произвести денормализацию чем наоборот.
А если есть ;)?
Опыт показывает, что нормализация, точнее — использование нормальных форм в чистом виде, даже если иметь ввиду третью нормальную форму (а тем паче уж более высшие формы..), является типичным жестоким сферическим конем в вакууме… Как и много чего из того, чему в универе учат эти замечательные преподаватели. И когда эти кони пытаются пойти по невспаханному полю реальной действительности, то не то что галопом скакать как ветер, обычным шагом идти им весьма и весьма сложно…

P.S.: не знаю как у кого, но из тех преподавателей, что работали на нашей кафедре, практиков было 1-2 штуки… Остальные теоретики такие, начитанные, просто жуть…
Скажу тебе как преподаватель :) который одно время читал «Теорию БД». К тому же я ещё и практик.

Так вот, тебе просто не везло с преподами :) не смогли объяснить нужность подобных вещей.
Нормализация — это правильная и нужная вещь.
Я встречал пару задач на практике, требовавшие вдумчивой нормализации.Нормальные формы я в них не считал, не задавался целью, но до 4-й дошел стопроцентно.
Так что сферических коней тут нет. Люди, придумавшие НФ, сделали это не из любви к искусству, они ведь тоже решали какие-то задачи таким способом. Тебе не приходило в голову работы Д. Кнута называть подобныи «конями»? Думаю, нет — потому что описанные алгоритмы используются на практике. Так и здесь.

Но нормализация только лишь ради неё самой — это зло. Всё должно быть в меру. Именно об этом и статья — показать вторую сторону медали нормализации.
Мне, кстати, тоже приходилось заниматься описанными в статье вещами — и производителтьность на базах с сотнями тысяч записей вырастала на порядки.

Так что автору — респект и +1 интерес.
Ну я и не говорил, что любая нормализация — зло, я написал, что использование этих самых НФ в чистом виде, скорее всего, представляет скорее академический интерес, ибо на практике (у меня лично) я хоть и стремился к какой-то из форм прийти, но встречались места, где нужно было чуточку денормализовать, где-то сильнее, а где-то и очень нормализовать, в зависимости от задачи. Не было у меня такого, чтобы вся структура БД была полностью и стопроцентно приведена к какой-то из нормальных форм, ну не было. Потому что где-то требуется скорость работы с данными по добавлению/удалению, где-то важны быстрые выборки… В общем, реальная действительность гораздо многообразнее какой-либо из НФ ))

А нормализация ради нормализации — да, зло.
> Опыт показывает, что нормализация, точнее — использование нормальных форм в чистом виде, даже если иметь ввиду третью нормальную форму (а тем паче уж более высшие формы..), является типичным жестоким сферическим конем в вакууме…

Чей опыт? Ваш личный? Вы делаете необоснованное обобщение, основываясь на своем (зачастую весьма ограниченном) опыте.

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

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

Вот это кеширование как раз и является денормализацией. А про «сливание справочных таблиц» в статье просто не хватает толкового примера.
Вот это кеширование как раз и является денормализацией.

Может подскажете, какая из форм указывает на то, что это денормализация?

А про «сливание справочных таблиц» в статье просто не хватает толкового примера.

Сомнительно, что это дает серьезную потерю в производительности.
Может подскажете, какая из форм указывает на то, что это денормализация?
Четвертый абзац, вообще это близко к третьей нормальной форме, хотя переубедить мне Вас сложно.
Формальное определение третьей нормальной формы:
www.citforum.ru/database/osbd/glava_23.shtml#_2_3_1_2

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

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

я собственно то же, что и Вы, хотел сказать — сохранение заказа это создание новой сущности, а не денормализация. т.е. выбран очень плохой пример.
Действительно, пример можно подобрать и более наглядный. Смысл такой: иногда, добавляя в таблицы атрибуты, напрямую или косвенно зависящие не от праймари кей, а от набора строк или значений неключевых столбцов в этой же строке, мы пораждаем дублирование информации, что можно счесть нарушение 3РФ. При этом необходимо дополнительно следить за целостностью данных, но зато можно выиграть на скорости выборки данных.

P.S. нормализация, нормальные формы — это cool но… если нужно нарушить 3НФ, то важно обосновать, как минимум себе, почему это сделано, какой будет выигрыш, и подстраховаться от возможных негативных последствий.
Интересно узнать результаты исследований для различных БД на счет примера про хранение blob'ов. Т.к. разного типа БД и разных производителей по-разному ведут себя в подобных запросах. ИМХО это сильно зависит от способа хранения blob'ов.
Крупные системы принято разбивать на OLTP и OLAP части. Для ввода данных используется строго нормализованная форма. А вот для отчетности данные аггрегируются в нужных разрезах, либо в большие плоские таблицы — реляционный OLAP, либо вообще в новую структуру — многомерные кубы. Все это описано в википедии. Для небольших систем конечно можно пытаться разместить все в одной базе, но придется идти на компромиссы между скоростью выборок, записи и надежностью системы.
Вообще денормализацией страдают и большие компании. Для них скорость превыше всего. Денормализация — совсем не зло, а бы сказал необходимость. К тому же визуально логическая, правда немного избыточна, но если с умомо подойти, то избыток сразу превращается в плюс.
И смотря что вводить в избыток, если добавлять к «собранной» таблице большой blob или текст — то это зло, а если поле byte или int — то этого субд даже не заметит
Нормализация это добро
Денормализация тоже добро
>Каждый раз, когда приходилось идти на сделку с совестью, нарушая принципы нормальных форм, оставалось ощущение неудовлетворённости, ложное осознание своей некомпетентности.

Как точно описаны мои мучения.

Хотел бы предложить ряд вопросов, на которые полезно для себя ответить перед проведением денормализации:
Точно ли высокая производительность действительно необходима в ближайшее будущее?
Много ли еще изменений будет вноситься до релиза, существенная ли часть требований удовлетворена?
Уверенные ли вы в выборе платформы, обслуживающей логику, настолько, что готовы доверить ей ответственность за операции над связанными данными?
Располагаете ли вы достаточными инструментами (тестами и диагностикой), чтобы вовремя обнаружить дефекты, внесенные вместе с денормализацией?
Нет ли других способов путем изменения архитектуры, кэширования и т.д. решить задачи, которые преследует денормализация?
Решают ли планируемые изменения проблему или есть намек на внесение изоляции между модулями приложения, например вынести данные о статике веб-сервиса в отдельный KV-store.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории