Как Views работает в DBM?

Question

Скажите, что у меня есть две такие таблицы:

Employers (id, name, .... , deptId).
Depts(id, deptName, ...).

Но эти данные не будут изменяться так часто, и мне нужен такой запрос

SELECT name, deptName FROM Employers, Depts 
    WHERE deptId = Depts.id AND Employers.id="ID"

будь как можно быстрее.

Мне в голову приходят два возможных решения:

• Денормализация таблицы:

  Несмотря на то, что с этим решением я потеряю некоторые из огромных преимуществ "нормализованных баз данных, но здесь производительность ОБЯЗАНА.

• Создание представления для этих денормализованных данных.

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

Или еще один способ задать один и тот же вопрос: представление «интерпретируется» каждый раз, когда вы делаете над ним запрос, или как работает представление Stuff в администраторе баз данных?.

Answer 1

Как правило, если вы не «материализуете» представление, которое является опцией в некоторых программах, таких как MS SQL Server, представление просто переводится в запросы к базовым таблицам и поэтому не быстрее и не медленнее, чем исходное (за исключением незначительное количество времени, необходимое для перевода запроса, что ничто по сравнению с фактическим выполнением запроса).

Откуда вы знаете, что у вас проблемы с производительностью? Вы профилируете его под нагрузкой? Вы убедились, что узким местом производительности являются эти две таблицы? Как правило, пока у вас нет достоверных данных, не думайте, что знаете, откуда возникают проблемы с производительностью, и не тратьте время на оптимизацию, пока вы не поймете, что оптимизируете правильную вещь - 80% проблем с производительностью возникают из % кода.

Answer 2

В комментарии к одному из ответов автор вопроса объясняет, что он ищет способ создания материализованного представления в MySQL.

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

Что вам нужно сделать, это:

1. Создать начальную материализацию результата вашего запроса.
2. Создать триггер при вставке в таблицу работодателей, который вставляет в материализованную таблицу все строки, соответствующие вновь вставленному работодателю.
3. Создать в таблице работодателей триггер удаления при удалении соответствующих строк из материализованной таблицы.
4. Создать триггер при обновлении в таблице работодателей, который обновляет соответствующие строки в материализованной таблице.
5. То же самое для таблицы отделов.

Это может работать нормально, если ваши базовые таблицы не часто обновляются; но вы должны знать о добавленной стоимости операций создания / обновления / удаления, как только вы это сделаете. Также вам нужно убедиться, что некоторые администраторы баз данных, которые не знают о вашей хитрости, не будут мигрировать базу данных без миграции триггеров, когда придет время. Так что документируйте это хорошо.

Answer 3

Если Depts.ID является первичным ключом этой таблицы и вы индексируете поле Employers.DeptID, то этот запрос должен оставаться очень быстрым даже для миллионов записей.

Денормализация не имеет смысла для меня в этом сценарии.

Вообще говоря, производительность представления будет практически равна производительности при выполнении самого запроса. Преимущество представления в том, что он просто абстрагирует этот запрос, поэтому вам не нужно об этом думать.

Вы можете использовать Материализованное представление (или, как некоторые говорят, «снимок»), но тогда ваши данные будут такими же свежими, как и ваше последнее обновление.

Answer 4

Похоже на преждевременную оптимизацию, если вы не знаете, что это явная и существующая проблема.

MySQL не материализует представления, они не быстрее запросов к базовым таблицам. Более того, в некоторых случаях они работают медленнее, поскольку оптимизируются хуже.

Но представления также «скрывают» вещи от разработчиков, поддерживающих код в будущем, чтобы они могли представить, что запрос менее сложен, чем на самом деле.