Как представления работают в DBM?

Question

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

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

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

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

быть настолько быстрым, насколько это возможно.

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

• Денормализовать таблицу:

  Несмотря на это, с этим решением я потеряю некоторые большие преимущества «нормализованных баз данных», но здесь ОБЯЗАТЕЛЬНА производительность.

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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