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

Ответ 1

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

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

[править]

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

A: Конечно.

• Сделайте резервную копию.
• Сделайте другую резервную копию на другом устройстве.
• Создайте новые таблицы с командами типа "select in newtable from oldtable...". Вам нужно будет сделать несколько объединений для объединения ранее определенных таблиц.
• Отбросьте старые таблицы.
• Переименуйте новые таблицы.

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

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

На самом деле это на самом деле больше, но это должно помочь вам начать.

Ответ 2

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

В целом, вставка-тяжелая база данных должна быть более нормализована, чем база данных с высокой отчетностью. Однако, конечно, YMMV...

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

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

Итак, нормализуем для ремонтопригодности, но денормализуем для оптимизации.