Создать представление или использовать innerjoins?

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

Некоторые из больших преимуществ использования представлений включают в себя:

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

2. осветление
   Часто заголовки столбцов не так наглядны, как могут быть. Представления позволяют добавлять ясность к возвращаемым данным.

3. Представление
   Производительность мудрых, взгляды не нанесут вам вреда. Однако вы не увидите прироста производительности при использовании представлений, поскольку MySQL не поддерживает материализованные представления .

4. Простота кодирования
   Представления могут использоваться для повторного использования сложных запросов с меньшим количеством ошибок пользователя.

5. Простота управления
   Это облегчает вашу жизнь, когда изменяется схема таблицы.

   Например, скажем, у вас есть таблица, которая содержит дома, которые вы homes_for_sale , homes_for_sale , но позже вы решите, что хотите, чтобы эта таблица обрабатывала все дома, которые вы когда-либо продавали / продавали в настоящее время, all_homes . Очевидно, что схема новой таблицы будет сильно отличаться от первой.

   Если у вас есть тонна запросов, вытаскивающих из homes_for_sale , теперь вам нужно пройти весь свой код и обновить все запросы. Это открывает вам ошибку пользователя и кошмар управления.

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

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

Но это может быть даже хуже, чем запуск голого SQL-запроса, поскольку MySQL может накапливать результаты базового запроса во временной таблице, чтобы вы могли использовать дополнительные предложения SQL в своем запросе против представления. Я говорю «может», потому что это зависит от алгоритма просмотра.

См. http://dev.mysql.com/doc/refman/5.6/en/view-algorithms.html для описания того, как MySQL использует алгоритм «merge» или «искушаемый» алгоритм для выполнения представления.

Если вы хотите материализованные представления, есть инструмент под названием FlexViews, который поддерживает материализованные представления:

Flexviews – это реализация материализованных представлений для MySQL. Он включает простой API, который используется для создания материализованных представлений и для их обновления. Преимущество использования Flexviews заключается в том, что материализованные представления постепенно обновляются, т. Е. Представления обновляются эффективно, используя специальные журналы, которые записывают изменения в таблицы базы данных. Flexviews включает инструменты, которые создают и поддерживают эти журналы. Представления, созданные Flexviews, включают поддержку JOINs и всех основных функций агрегации.

Представление – это просто хранимый текстовый запрос. Вы можете применить к нему ГДЕ и ЗАКАЗ, план выполнения будет рассчитан с учетом этих положений. Я думаю, было бы полезно, если бы вы захотели сохранить свой код «чистым». Что нужно иметь в виду, так это то, что изменить представление немного сложнее, поэтому, если вы не совсем уверены в столбцах или измените последнее, придерживайтесь запроса.

О производительности – ТО ЖЕ!

С наилучшими пожеланиями!

Создание представления предпочтительнее, если вы:

• Уверен, что требуемые столбцы
• Хотите снова использовать свое мнение в другом месте
• Вам нравится кодирование абстрактным образом. (Скрытие технических деталей)
• Нужен быстрый доступ, создавая на нем индекс.
• Конкретный доступ к нескольким пользователям (точка взята из комментариев)

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

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

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

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

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