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