История SQL из 2-х частей. Всегда ли хороши представления SQL и как я могу решить этот пример?

Question

История SQL из 2-х частей. Всегда ли хороши представления SQL и как я могу решить этот пример?

0

Я создаю приложение для отчетов, и поэтому я собираю огромное количество данных. Часть моего подхода к созданию приложения гибким способом заключается в использовании представлений SQL, чтобы снять нагрузку с БД, если все пользователи уходят.

Один пример:

    mysql_query("CREATE VIEW view_silverpop_clicks_baby_$email AS SELECT view_email_baby_position.EmailAddress, view_email_baby_position.days, silverpop_campaign_emails.id, silverpop_actions.`Click Name` , silverpop_actions.`Mailing Id`
FROM silverpop_actions
INNER JOIN view_email_baby_position ON (silverpop_actions.Email = view_email_baby_position.EmailAddress ) , silverpop_campaign_emails
WHERE silverpop_campaign_emails.id = $email
AND view_email_baby_position.days
BETWEEN silverpop_campaign_emails.low
AND silverpop_campaign_emails.high
AND silverpop_actions.`Event Type` = 'Click Through'") or die(mysql_error());

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

    $sql = "SELECT count(*) as count FROM `view_silverpop_clicks_baby_$email` WHERE `Click Name` LIKE '$countme%'";

Мой вопрос состоит из двух частей:

Всегда ли хорошие представления? Ты можешь слишком много?
Могу ли я создать еще один набор представления для кэширования переменной count в второй фрагмент кода. Если так как я мог подойти к этому? Я не могу все еще это сделать.

Спасибо!

MrFidge 01 дек. 2009, в 13:06

Источник

1

Представления не снимают нагрузку с БД из-за большого количества пользователей. Это просто логическая конструкция, чтобы скрыть сложность вашего запроса.
Khb 01 дек. 2009, в 11:41
0

У меня сложилось впечатление, что представления кэшируются - значит, они значительно ускоряют доставку данных?
MrFidge 01 дек. 2009, в 11:43
1

План выполнения запроса кэшируется не самими данными. Для кеширования данных вам нужно индексированное или материализованное представление.
Goran 01 дек. 2009, в 11:52

Показать ещё 1 комментарий

Теги:

mysql

sql

sql-view

2 ответа

Ещё вопросы

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

RC. · Answer 1 · 2009-12-01T10-49-00.000Z

Чтобы ответить на ваши вопросы.

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

2.) Наличие другого набора представлений не будет кэшировать переменную count, поэтому было бы не выгодно с этой точки зрения.

Сказав это, я думаю, что у вас есть недоразумение в отношении того, что на самом деле делает. Представление - это просто определение конкретного оператора SQL, и оно не кэширует данные. Когда вы выполняете SELECT * FROM myView;, база данных все еще выполняет оператор select, определенный в определении CREATE VIEW так же, как если бы пользователь выполнял эту инструкцию.

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

Некоторые полезные виды использования:

Создавайте упрощенные/чистые операторы SQL для сложных запросов (что вы делаете)
Безопасность. Если у вас есть таблицы, в которых вы хотите, чтобы пользователь мог видеть некоторые столбцы или строки, но не другие столбцы/строки, вы ограничиваете доступ к базовой таблице и создаете представление базовой таблицы, которая выбирает только столбцы/строки, которые пользователь также должен иметь доступ.
Создание агрегатов таблиц

Goran · Answer 2 · 2009-12-01T09-56-00.000Z

Представления используются оптимизатором запросов, поэтому они часто помогают более эффективно запрашивать информацию.

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

Некоторые виды никогда не используются, поэтому они представляют сложность игл, что плохо.
Индексированные представления не могут ссылаться на другие представления (mssql), поэтому вряд ли стоит создавать такой вид.