Действительно лучше использовать нормализованные таблицы?
С laravel-mix 4.x они заменили uglify на terser ( Список изменений ). Вы должны изменить свой webpack.mix.js :
if (mix.inProduction()) {
mix.options({
terser: {
terserOptions: {
compress: {
drop_console: true
}
}
}
});
mix.version();
}
7 ответов
Это зависит... присоединяясь к таблицам, по сути медленнее, чем наличие одной большой таблицы, к которой 'предварительно присоединяются' т.е. денормализовывают. Однако путем денормализовывания Вы собираетесь создать дублирование данных, и Ваши таблицы будут больше. Нормализация рассматривается как хорошая вещь, потому что она создает базы данных, которые могут ответить на 'любой' вопрос, если она правильно сделана, можно создать выбор для получения до данных. Дело обстоит не так в некоторых других формах DB, и это - теперь (главным образом) историческая нерелевантность, нормализованное/отношение DB выиграл то сражение.
Назад к Вашему вопросу, с помощью денормализации, чтобы заставить вещи пойти быстрее хорошо принятая техника. Обычно лучше выполнить Ваш DB некоторое время, таким образом, Вы знаете, что денормализовать и что оставить в покое, и также распространено оставить данные в своей 'корректной' нормализованной форме и данные получения по запросу в ряд денормализованных таблиц отчетов регулярно. Если тот процесс сделан, поскольку часть отчета выполняет себя затем, данные всегда актуальны также.
Как пример сверхнормализации я видел DBS в прошлом, где дни недели и месяцы года были вытащены в отдельные таблицы - сами даты были нормализованы - можно зайти слишком далеко.
Jeff записал об этом, сопровождаемом горячим обсуждением. Это - также предмет большого обсуждения Так, например, что является лучшим проектированием баз данных больше таблиц или больше столбцов. Поскольку другие указали, используют здравый смысл и не сверхнормализуют.
Этот вопрос повторяется в целом слишком часто. Основная причина - то, что SQL, самый популярный язык базы данных огромным полем, и все его самые популярные реализации, объединяет логический дизайн таблицы с физическим дизайном таблицы.
Вечный ответ - то, что необходимо всегда нормализовать логические таблицы, но прагматический ответ осложнен тем, что единственный способ реализовать определенную оптимизацию при существующих реализациях SQL состоит в том, чтобы денормализовать физический дизайн таблицы (сам не плохая вещь), который, в тех реализациях, требует денормализовывания логического дизайна таблицы.
Короче говоря, это зависит. Иногда денормализация важна для производительности, но как все остальное связанное с производительностью необходимо иметь размеры, иметь размеры, мера перед ровным рассмотрением потери работоспособности по этому маршруту.
Необходимо провести некоторое исследование на различиях между базами данных OLTP (Online Transaction Processing) и OLAP (Online Analytical Processing).
Короче говоря, системы баз данных, которые затронуты, прежде всего, с записью транзакций (OLTP), обычно структурируются более нормализованным способом, уменьшая дублирование данных и упрощая создание и обновляя записей за счет оптимизированного поиска данных.
Системы баз данных, которые более касаются поиска данных и анализа (OLAP), обычно структурируются менее нормализованным способом, жертвуя оптимизацией хранения данных так для максимизации скорости запросов и анализа.
Нормализация базы данных и Денормализация в основе этого компромисса.
В моем большом опыте с базами данных Oracle OLTP, некоторые из них очень большой и занятый, я могу честно сказать, что не могу помнить когда-либо сталкивавшийся со случаем, где "денормализация для производительности" действительно требовалась. Я, однако, видел много случаев, где кто-то решил заранее, что денормализация должна быть применена из-за их страха, неуверенности и сомнения относительно потенциальных проблем производительности. Это обычно делалось без любого сравнительного тестирования, и неизменно я нахожу, что никакое повышение производительности не было достигнуто на самом деле - но код обслуживания данных стал намного более сложным, чем это было бы.
OLAP является совсем другим животным, и я не имею возможности комментировать об этом.
Причина, почему нормализация, как было известно, повредила производительность, состоит в том, потому что соединения являются довольно дорогими. Если существуют записи N в записях таблицы X и M в таблице Y, то соединение X и Y составляет временную таблицу со столько же сколько записи N*M. Хотя существуют приемы оптимизации, которые база данных использует для не генерации всей таблицы, если это не нужно, она, тем не менее, должна обработать все записи.
Денормализация является процессом, посредством чего Вы помещаете данные, часто используемые вместе в единственной таблице для увеличения производительности в пользе некоторой чистоты базы данных. Большинство находит, что это приемлемая торговля, даже идя, насколько разработать схему, намеренно денормализованную для пропуска посреднического шага.
Производительность является обратной на сумму нормализации, сделанной на RDBMS. Однако чем более нормальны таблицы, тем меньше вероятности, там для ошибок. Существует точка туда, где производительность RDBMS может быть повреждена денормализацией в точке туда, где все данные сохранены в одной таблице.