Должен ли я нормализовать мою БД или нет?

Question

При разработке схемы для БД (например, MySQL) возникает вопрос, следует ли полностью нормализовать таблицы.

С одной стороны, соединения (и ограничения внешнего ключа и т. Д.) Очень медленные, а с другой стороны, вы получаете избыточные данные и возможность несогласованности.

Является ли "оптимизировать последний" правильным подходом здесь? то есть создайте обычную БД, а затем посмотрите, что можно денормализовать для достижения оптимального прироста скорости.

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

Должен ли тот факт, что эта БД будет сильно загружена, повлиять на решение?

Answer 1

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

С практической точки зрения: сделайте это правильно, прежде чем быстро. Мы, люди, очень плохо предсказываем, где возникнут узкие места. Сделайте базу данных великолепной, измерьте производительность за приемлемый период времени, а затем решите, нужно ли вам сделать это быстрее. Прежде чем денормализовать и пожертвовать точностью, попробуйте другие методы: можете ли вы получить более быстрый сервер, соединение, драйвер БД и т. Д.? Могут ли хранимые процедуры ускорить процесс? Как индексы и их коэффициенты заполнения? Если те и другие методы производительности и настройки не справляются, только тогда рассмотрите возможность денормализации. Затем измерьте производительность, чтобы убедиться, что вы получили увеличение скорости, за которое вы «заплатили». Убедитесь, что вы выполняете оптимизацию, а не пессимизацию.

[править]

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

A: Конечно.

1. Сделайте резервную копию.
2. Сделайте еще одну резервную копию на другое устройство.
3. Создание новых таблиц с помощью команд типа «выбрать в новую таблицу из старой таблицы ...». Вам нужно будет выполнить несколько объединений, чтобы объединить ранее отдельные таблицы.
4. Удалите старые таблицы.
5. Переименуйте новые таблицы.

НО ... рассмотрим более надежный подход:

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

На самом деле это еще не все на практике, но это должно помочь вам начать.

Answer 2

Модель использования вашей базы данных (интенсивная вставка или интенсивная отчетность) определенно повлияет на вашу нормализацию. Кроме того, вы можете захотеть посмотреть на свою индексацию и т. Д., Если вы видите значительное замедление с нормализованными таблицами. Какую версию MySQL вы используете?

Как правило, база данных с большим количеством вставок должна быть больше нормализована, чем база данных с большим объемом отчетов. Тем не менее, YMMV конечно ...

Answer 3

Нормальный дизайн - это место для старта; Во-первых, сделайте все правильно, потому что вам не нужно делать это быстро.

Забота о дорогостоящих соединениях часто основывается на опыте с плохими проектами. По мере того, как дизайн становится более нормальным, число таблиц в дизайне обычно увеличивается, в то время как количество столбцов и строк в каждой таблице уменьшается, число объединений в дизайне увеличивается с уменьшением числа объединений, показатели становятся более полезными, & c. Другими словами: хорошие вещи случаются.

И нормализация - это только один способ получить нормальный дизайн ...

Answer 4

Денормализация необходима в операционной системе только в редких случаях. Одна система, для которой я сделал модель данных, имела 560 таблиц или около того (в то время это была самая большая система J2EE, построенная в Австралии) и имела только 4 фрагмента денормализованных данных. Два элемента представляли собой денормализованные таблицы поиска, предназначенные для упрощения сложных экранов поиска (один представлял собой материализованное представление), а два других были добавлены в соответствии с конкретными требованиями к производительности.

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

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

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

Answer 5

Откуда вы взяли, что «объединения (и ограничения внешнего ключа и т. Д.) Очень медленные»? Это очень расплывчатое утверждение, и обычно у IMO проблем с производительностью нет.

Answer 6

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

Только если это не поможет, вы должны попробовать денормализованные таблицы. Обязательно сравните и вставки, и запросы до и после денормализации, поскольку вполне вероятно, что вы замедляете вставки.

Answer 7

Общий подход к решению этой проблемы заключается в том, чтобы сначала полностью нормализовать вашу базу данных до 3-й нормальной формы, а затем денормализовать в зависимости от производительности и удобства доступа. Этот подход, как правило, наиболее безопасный, так как вы принимаете конкретное решение, а не нормализуетесь по умолчанию.

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

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

Из этого должно быть очевидно, что денормализация должна быть исключением. В любой производственной базе данных я бы ожидал, что подавляющее большинство ее - 95% плюс - будет в 3-й нормальной форме, с лишь несколькими ненормализованными структурами.

Answer 8

Является ли "оптимизировать последний" правильным подходом здесь? то есть создайте обычную нормализованную БД, а затем посмотрите, что можно денормализовать для достижения оптимального прироста скорости.

Я бы сказал, да. Мне приходилось сталкиваться с плохо структурированными БД слишком много раз, чтобы потворствовать «плоским» БД без долгих размышлений.

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

Answer 9

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

Это баланс, так что не оптимизируйте преждевременно. Причина в том, что с денормализованным дизайном базы данных, как правило, становится трудно работать. Вам понадобятся некоторые показатели, поэтому проведите стресс-тестирование базы данных, чтобы определить, хотите ли вы денормализовать или нет.

Так что нормализуйте для удобства обслуживания, но денормализуйте для оптимизации.