Подтвердить что ты не робот

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

У меня есть нормализованная база данных с внешними ключами/первичными ключами, дающими одну-две базы данных.

Я планирую получить доступ к этой базе данных с помощью PHP для основного интерфейса/бэкэнд-дисплея. Теперь мой вопрос исходит из этих двух рассмотренных запросов:

CREATE VIEW `view` AS
  SELECT
    functiondetails.Detail,
    functionnames.ID,
    functionnames.FunctionName,
    functionnames.Catogory
  FROM functiondetails
    INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID

или

SELECT
  functiondetails.Detail,
  functionnames.ID,
  functionnames.FunctionName,
  functionnames.Catogory
FROM functiondetails
  INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID

В запросе нет ошибки, поскольку я запускал оба без проблем, но мой общий вопрос:

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

$Query = $MySQli->prepare("
  SELECT
    functiondetails.Detail,
    functionnames.ID,
    functionnames.FunctionName,
    functionnames.Catogory
  FROM functiondetails
    INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID
")
$Query->execute();
$Results = $Query->fetch_results();
$Array = $Results->fetch_array(MYSQLI_ASSOC);

Или выбрать из моего представления?

$Query = $MySQLi->prepare("SELECT * FROM `view`");
$Query->execute();
$Results = $Query->fetch_results();
$Array = $Results->fetch_array(MYSQLI_ASSOC);

Итак, какой из них был бы лучшим методом для запроса моей базы данных?

4b9b3361

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

С уважением!

Ответ 5

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

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

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

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

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