Должен ли я нормализовать свою БД или нет?
при разработке схемы для БД (например, MySQL) возникает вопрос, следует ли полностью нормализовать таблицы.
с одной стороны присоединяется (и ограничения внешнего ключа и т. д.) очень медленно, а с другой стороны вы получаете избыточные данные и потенциал для несогласованности.
"оптимизировать последний" правильный подход здесь? т. е. создайте по книге нормализованную БД, а затем посмотрите, что можно денормализовать для достижения оптимального коэффициента усиления скорости.
мой страх, что касается этого подхода, я остановлюсь на дизайне БД, который может быть недостаточно быстрым, но на этом этапе рефакторинг схемы (при поддержке существующих данных) будет очень болезненным. Вот почему у меня возникает соблазн временно забыть все, что я узнал о "правильной" практике РСУБД, и попробовать подход "плоского стола" на этот раз.
должен ли тот факт, что эта БД будет вставлять-тяжелый эффект решения?
9 ответов
философский ответ: субоптимальные (реляционные) базы данных изобилуют аномалиями вставки, обновления и удаления. Все это приводит к несогласованности данных, что приводит к плохому качеству данных. Если вы не можете доверять точности этих данных, что в этом хорошего? Спросите себя: хотите ли вы, чтобы правильные ответы были медленнее или чтобы неправильные ответы были быстрее?
как практический вопрос: получите его прямо, прежде чем вы получите его быстро. Мы, люди, очень плохо предсказываем, где возникнут узкие места. Сделайте базу данных отличной, измерьте производительность в течение приличного периода времени, а затем решите, нужно ли делать это быстрее. Прежде чем денормализовать и пожертвовать точностью, попробуйте другие методы: можете ли вы получить более быстрый сервер, соединение, драйвер БД и т. д.? Могут ли хранимые процедуры ускорить процесс? Как индексы и их коэффициенты заполнения? Если те и другие методы производительности и настройки не делают трюк, только тогда рассмотрим денормализацию. Затем измерьте производительность, чтобы убедиться, что вы получили увеличение скорости, за которое вы "заплатили". Убедитесь, что вы выполняете оптимизацию, а не пессимизацию.
[edit]
Q: так если я оптимизирую последнее, то можете вы рекомендовать разумный способ миграции данные после изменения схемы? Если, например, я решаю избавиться от таблица поиска - как я могу перенести существующие базы данных для этого нового дизайна?
A: Конечно.
- сделать резервную копию.
- сделать еще одна резервная копия на другое устройство.
- создать новые таблицы с " выберите в newtable из oldtable...- введите команды. Вам нужно будет сделать некоторые объединения, чтобы объединить ранее различные таблицы.
- отбросьте старые таблицы.
- переименовать новые таблицы.
но... рассмотрим более надежный подход:
создайте некоторые представления на ваших полностью нормализованных таблицах прямо сейчас. Эти представления (виртуальные таблицы, "окна" на данные... спросите меня, хотите ли вы узнать больше об этой теме) будет иметь тот же определяющий запрос, что и шаг три выше. Когда вы пишете логику приложения или уровня БД, используйте представления (по крайней мере, для доступа на чтение; обновляемые представления... ну, interestsing). Тогда, если вы денормализовать позже, создать новую таблицу, как указано выше, падение зрения, переименовать новую базовую таблицу, что было. Ваше приложение / DB-layer не будет знать разницы.
на самом деле это больше на практике, но это тебе стоит начать.
шаблон использования вашей базы данных (insert-heavy vs.reporting-heavy) определенно повлияет на вашу нормализацию. Кроме того, вы можете посмотреть на свою индексацию и т. д. если вы видите значительное замедление с нормализованными таблицами. Какую версию MySQL вы используете?
В общем случае база данных insert-heavy должна быть больше нормализовано, чем отчетность-тяжелая база данных. Тем не менее, YMMV, конечно...
нормальный дизайн - это место для начала; получите его правильно, во-первых, потому что вам, возможно, не нужно делать это быстро.
беспокойство о времени дорогостоящих соединений часто основаны на опыте с плохими проектами. По мере того как дизайн становится более нормальным, количество таблиц в дизайне обычно увеличивается, в то время как количество столбцов и строк в каждой таблице уменьшается, количество союзов в дизайне увеличивается по мере уменьшения количества соединений, показатели становятся более полезными и т. д. Другими словами: хорошо всякое случается.
и нормализация-это только один способ получить нормальный дизайн...
является ли" оптимизировать последний " правильным подходом здесь? т. е. создайте по книге нормализованную БД, а затем посмотрите, что можно денормализовать для достижения оптимального коэффициента усиления скорости.
Я бы сказал, Да. Мне приходилось иметь дело с плохо структурированными DBs слишком много раз, чтобы потворствовать "плоскому столу" без особых размышлений.
на самом деле вставки обычно ведут себя хорошо на полностью нормализованных DBs, поэтому, если это insert heavy, это не должно быть фактором.
в базе данных insert-heavy я бы определенно начал с нормализованных таблиц. Если у вас проблемы с производительностью запросов, я бы сначала попытался оптимизировать запрос и добавить полезные индексы.
только если это не помогает, вы должны попробовать денормализованные таблицы. Не забудьте проверить как вставки, так и запросы до и после денормализации, так как вероятно, что вы замедляете свои вставки.
общий подход к проектированию для этой проблемы заключается в том, чтобы сначала полностью нормализовать вашу базу данных до 3-й нормальной формы, а затем денормализовать в зависимости от производительности и простоты доступа. Этот подход имеет тенденцию быть самым безопасным, поскольку вы принимаете конкретное решение по дизайну, а не нормализуете по умолчанию.
"по мере необходимости" - это сложный бит, который требует опыта. Нормализация-это довольно "заученная" процедура, которой можно научить, зная, где денормализация меньше точный и будет зависеть от использования приложения и бизнес-правил и, следовательно, будет отличаться от приложения к приложению. Все ваши решения denormalisation должны быть обоснованными, чтобы профессиональный сотрудник.
например, если у меня есть один ко многим отношениям корабль A к B, я бы в большинстве случаев оставил это нормализованным, но если я знаю, что бизнес только когда-либо имеет, скажем, два вхождения B для каждого A, это вряд ли изменится, есть ограниченные данные в B запись. и они обычно будут отбирать данные B с записью A, которую я, скорее всего, расширю записью A с двумя вхождениями полей B. Конечно, большинство проходящих DBA сразу же отметят это как возможную проблему дизайна, поэтому вы должны быть в состоянии убедительно аргументировать свое оправдание денормализации.
Это должно быть очевидно из этого, что denormalisation должны быть исключением. В любой производственной базе данных я бы ожидал подавляющее большинство it-95% плюс-быть в 3-й нормальной форме, с горсткой денормализованных структур.
откуда вы взяли идею, что " присоединяется (и ограничения внешнего ключа и т. д.) очень медленно"? Это очень расплывчатое заявление, и обычно у IMO нет проблем с производительностью.
Denormalisation очень редко нужен на оперативной системе. Одна система, для которой я сделал модель данных, имела 560 таблиц или около того (в то время это была самая большая система J2EE, построенная в Австралазии) и имела только 4 части денормализованных данных. Два из этих элементов представляли собой денормализованные таблицы поиска, предназначенные для использования сложных экранов поиска (один из них представлял собой материализованный вид), а два других были добавлены в соответствии с конкретными требованиями к производительности.
Не преждевременно оптимизация базы данных с помощью денормализованных данных. Это рецепт для текущих проблем целостности данных. Кроме того, всегда используйте триггеры базы данных для управления денормализованными данными - не полагайтесь на приложение.
наконец, если вам нужно улучшить производительность отчетности, подумайте о создании Data mart или другой отдельной денормализованной структуры для отчетности. Отчеты, объединяющие требования к представлению агрегатов в реальном времени, рассчитанных на больших объемах данных, встречаются редко и имеют тенденцию только происходить в нескольких направлениях бизнеса. Системы, которые могут это сделать, как правило, довольно сложно построить и, следовательно, дорого.
У вас почти наверняка будет только небольшое количество отчетов, которые действительно нуждаются в современных данных, и они почти всегда будут оперативными отчетами, такими как списки дел или отчеты об исключениях, которые работают с небольшими объемами данных. Все остальное можно отправить в data mart, для чего, вероятно, достаточно ночного обновления.
Я не знаю, что вы имеете в виду о создании базы данных по учебнику потому что большинство книг, которые я читал о базах данных, включают тему оптимизации, что то же самое, что денормализация дизайна базы данных.
Это акт баланса, поэтому не оптимизируйте преждевременно. Причина в том, что денормализованный дизайн базы данных, как правило, становится трудным для работы. Вам понадобятся некоторые показатели, поэтому сделайте стресс-тестирование базы данных, чтобы решить, хотите вы этого или нет wan'T, чтобы денормализовать.
поэтому нормализуйте для ремонтопригодности, но денормализуйте для оптимизации.