Должен ли я нормализовать мою БД или нет?
При разработке схемы для БД (например, MySQL) возникает вопрос, следует ли полностью нормализовать таблицы.
С одной стороны, объединения (и ограничения внешнего ключа и т. Д.) Очень медленные, а с другой стороны, вы получаете избыточные данные и потенциальную несогласованность.
Является ли "оптимизация последней" правильным подходом здесь? то есть создайте индивидуально стандартизированную БД и затем посмотрите, что можно денормализовать для достижения оптимального прироста скорости.
Я опасаюсь, что при таком подходе я остановлюсь на дизайне БД, который может быть недостаточно быстрым, но на этом этапе рефакторинг схемы (при поддержке существующих данных) будет очень болезненным. Вот почему у меня возникает соблазн просто временно забыть все, что я узнал о "правильных" методах СУБД, и на этот раз попробовать подход "плоского стола".
Должен ли тот факт, что эта БД будет сильно загружена, повлиять на решение?
9 ответов
Философский ответ: Субоптимальные (реляционные) базы данных изобилуют аномалиями вставки, обновления и удаления. Все это приводит к противоречивым данным, что приводит к низкому качеству данных. Если вы не можете доверять точности своих данных, что хорошего в этом? Задайте себе вопрос: хотите ли вы правильные ответы медленнее или же вы хотите быстрее получать неправильные ответы?
С практической точки зрения: сделайте это правильно, прежде чем быстро. Мы, люди, очень плохо предсказываем, где возникнут узкие места. Сделайте базу данных великолепной, измерьте производительность за приемлемый период времени, а затем решите, нужно ли вам сделать это быстрее. Прежде чем денормализовать и пожертвовать точностью, попробуйте другие методы: можете ли вы получить более быстрый сервер, соединение, драйвер БД и т. Д.? Могут ли хранимые процедуры ускорить процесс? Как индексы и их коэффициенты заполнения? Если эти и другие методы производительности и настройки не помогают, только тогда рассмотрите возможность денормализации. Затем измерьте производительность, чтобы убедиться, что вы получили увеличение скорости, за которое вы "заплатили". Убедитесь, что вы выполняете оптимизацию, а не пессимизацию.
[редактировать]
В: Так что, если я оптимизирую в последнюю очередь, можете ли вы порекомендовать разумный способ переноса данных после изменения схемы? Если, например, я решу избавиться от справочной таблицы - как я могу перенести существующие базы данных в этот новый дизайн?
A: Конечно.
- Сделайте резервную копию.
- Сделайте еще одну резервную копию на другое устройство.
- Создайте новые таблицы с помощью команд типа "выбрать в новую таблицу из старой таблицы...". Вам нужно будет сделать несколько объединений, чтобы объединить ранее отдельные таблицы.
- Оставьте старые таблицы.
- Переименуйте новые таблицы.
НО... рассмотрим более надежный подход:
Создайте несколько видов ваших полностью нормализованных таблиц прямо сейчас. Эти представления (виртуальные таблицы, "окна" в данных... спросите меня, хотите ли вы узнать больше об этой теме) будут иметь тот же определяющий запрос, что и третий шаг выше. Когда вы пишете свое приложение или логику уровня БД, используйте представления (по крайней мере, для доступа на чтение; обновляемые представления... ну, это интересно). Затем, если вы денормализуетесь позже, создайте новую таблицу, как указано выше, удалите представление, переименуйте новую базовую таблицу, какой бы она ни была. Ваше приложение / слой DB не будет знать разницу.
На самом деле есть еще кое-что, но это должно помочь вам начать.
Модель использования вашей базы данных (интенсивная вставка или интенсивная отчетность) определенно повлияет на вашу нормализацию. Кроме того, вы можете захотеть взглянуть на свою индексацию и т. Д., Если вы видите значительное замедление с нормализованными таблицами. Какую версию MySQL вы используете?
В общем случае база данных с большим количеством вставок должна быть более нормализованной, чем база данных с большим объемом отчетов. Тем не менее, YMMV конечно...
Нормальный дизайн - это место для старта; Во-первых, сделайте это правильно, потому что вам не нужно делать это быстро.
Забота о дорогостоящих соединениях часто основывается на опыте с плохими проектами. По мере того, как дизайн становится более нормальным, число таблиц в дизайне обычно увеличивается, в то время как количество столбцов и строк в каждой таблице уменьшается, число объединений в дизайне увеличивается с уменьшением числа объединений, показатели становятся более полезными, &c. Другими словами: хорошие вещи случаются.
И нормализация - это только один способ получить нормальный дизайн...
Денормализация требуется только в операционной системе. Одна система, для которой я сделал модель данных, имела 560 таблиц или около того (в то время это была самая большая система J2EE, построенная в Австралии) и имела только 4 фрагмента денормализованных данных. Два элемента представляли собой денормализованные таблицы поиска, предназначенные для упрощения сложных экранов поиска (один представлял собой материализованное представление), а два других были добавлены в соответствии с конкретными требованиями к производительности.
Не преждевременно оптимизируйте базу данных с денормализованными данными. Это рецепт для постоянных проблем целостности данных. Кроме того, всегда используйте триггеры базы данных для управления денормализованными данными - не полагайтесь на то, что приложение делает это.
Наконец, если вам нужно улучшить производительность отчетности, рассмотрите возможность создания витрины данных или другой отдельной денормализованной структуры для отчетности. Отчеты, которые сочетают в себе требования представления в реальном времени агрегатов, рассчитанных на большие объемы данных, редки и, как правило, появляются только в нескольких направлениях бизнеса. Системы, которые могут сделать это, как правило, довольно сложны в построении и, следовательно, дороги.
Вы почти наверняка будете иметь только небольшое количество отчетов, которые действительно требуют самых последних данных, и они почти всегда будут оперативными отчетами, такими как списки дел или исключений, которые работают с небольшими объемами данных. На витрину данных может быть добавлено все остальное, для чего, вероятно, достаточно ночного обновления.
Откуда вы взяли, что "объединения (и ограничения внешнего ключа и т. Д.) Очень медленные"? Это очень расплывчатое утверждение, и обычно у IMO проблем с производительностью нет.
Является ли "оптимизация последней" правильным подходом здесь? то есть создайте индивидуально стандартизированную БД и затем посмотрите, что можно денормализовать для достижения оптимального прироста скорости.
Я бы сказал, да. Мне приходилось сталкиваться с плохо структурированными БД слишком много раз, чтобы потворствовать "плоским" БД без долгих раздумий.
На самом деле, вставки обычно ведут себя хорошо на полностью нормализованных БД, поэтому, если они слишком тяжелые, это не должно быть фактором.
В базе данных с большой вставкой я бы определенно начал с нормализованных таблиц. Если у вас есть проблемы с производительностью запросов, я сначала попытался бы оптимизировать запрос и добавить полезные индексы.
Только если это не поможет, вы должны попробовать денормализованные таблицы. Обязательно сравните и вставки, и запросы до и после денормализации, так как вполне вероятно, что вы замедляете вставки.
Общий подход к проектированию для этой проблемы заключается в том, чтобы сначала полностью нормализовать вашу базу данных до 3-й нормальной формы, а затем денормализовать в зависимости от производительности и удобства доступа. Этот подход, как правило, наиболее безопасный, так как вы принимаете конкретное решение, а не нормализуетесь по умолчанию.
"При необходимости" - это сложный момент, который требует опыта. Нормализация - это довольно "наизусть" процедура, которую можно научить, зная, где денормализовать, менее точно и будет зависеть от использования приложения и бизнес-правил и, следовательно, будет отличаться от приложения к приложению. Все ваши решения о денормализации должны быть оправданы коллегами-профессионалами.
Например, если у меня отношения "один ко многим", судно "А" к "БИ" в большинстве случаев оставило бы это нормализованным, но если я знаю, что в бизнесе только когда-нибудь, скажем, два случая В для каждого А, это вряд ли изменится, в B-записи есть ограниченные данные. и они, как правило, возвращают данные B с записью A, я, скорее всего, расширю запись A с двумя вхождениями полей B. Конечно, большинство проходящих администраторов баз данных сразу же отметят это как возможную проблему проектирования, поэтому вы должны быть в состоянии убедительно аргументировать свое обоснование денормализации.
Из этого должно быть очевидно, что денормализация должна быть исключением. В любой производственной базе данных я бы ожидал, что подавляющее большинство ее - 95% плюс - будет в 3-й нормальной форме, с лишь несколькими ненормализованными структурами.
Я не знаю, что вы имеете в виду под созданием базы данных , потому что большинство книг, которые я читал о базах данных, содержат тему об оптимизации, которая аналогична денормализации дизайна базы данных.
Это акт баланса, поэтому не оптимизируйте преждевременно. Причина в том, что с денормализованным дизайном базы данных, как правило, становится трудно работать. Вам понадобятся некоторые показатели, поэтому проведите стресс-тестирование базы данных, чтобы решить, хотите ли вы денормализовать или нет.
Так что нормализуйте для удобства обслуживания, но денормализуйте для оптимизации.