mysql Views vs Stored Procedure

Question

В настоящее время я разрабатываю свой mysql db для приложения, которое я разрабатываю.

Мне нравится, когда Stored Procedures короткие и читаемые, и так как мой дб участие некоторых join заявления, я подумал, что я должен создать Views со всеми joins и запрашивать эти Views из моего Stored Procedures.

Сначала это звучит замечательно, но когда я, хотя о производительности, я понял, что всякий раз, когда Stored Procedure называется она будет работать как минимум 2 запросов:

1. View запрос
2. Stored Procedure запрос на том, что View

при использовании join заявления внутри Stored Procedure я только по запросу делает присоединение и к selectio n из соединения.

Я прав?

Если да - то, что будет хорошей практикой для поддержания отличной производительности разработки с точки зрения элегантного написания кода?

Answer 1

«отличное развитие» и «элегантный код» - это два мира друг от друга. Вы не должны спаривать их так близко.

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

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

Если вы действительно обеспокоены тем, что у вас четкость кода, я бы посоветовал рассмотреть, какие данные вы фактически используете из своих заявлений о соединении, чтобы узнать, можете ли вы их сократить или разбить. Например, вы используете несколько столбцов или строк данных? Или вы просто запрашиваете одно значение? Если последнее, подумайте о создании функции, которая возвращает это значение. Это также поможет отделить ваш код от хранимой процедуры.

Answer 2

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

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

См. MySQL documentation. (Обратите внимание на комментарий пользователя, в котором говорится, что некоторые предложения представления только предотвращают вложение/слияние, когда они находятся во внешнем выражении select.) Или this dba.stackexchange.com google 'mysql view optimization' hit.