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

Question

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

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

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

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

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

Answer 1

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

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

[править]

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

A: Конечно.

1. Сделайте резервную копию.
2. Сделайте еще одну резервную копию на другом устройстве.
3. Создайте новые таблицы с командами типа «select in newtable from oldtable ...». Вам нужно будет сделать несколько соединений для объединения ранее определенных таблиц.
4. Бросьте старые столы.
5. Переименуйте новые таблицы.

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

Так что нормализовать для ремонтопригодности, но денормализовать для оптимизации.

Answer 9

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

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

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