MySQL: представления против хранимых процедур

Question

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

С точки зрения выбора данных, особенно при рассмотрении выбора, который, по сути, представляет собой ненормализацию (объединения) и совокупный (avg или max, подзапросы с подсчетами и т. Д.) Выбор данных, что является правильным выбором в MySQL 5.x? Вид? Или хранимая процедура?

Представления, с которыми мне удобно - вы знаете, как должен выглядеть ваш запрос SELECT, поэтому просто создайте его, убедитесь, что он проиндексирован и еще много чего, а затем просто выполните CREATE VIEW [View] AS SELECT [...]. Затем в моем приложении я рассматриваю представление как таблицу только для чтения - она ​​представляет ненормализованную версию моих нормализованных данных.

Какие здесь недостатки - если таковые имеются? И что изменится (прибыль или убыток), если я перенесу точно такой же оператор SELECT в хранимую процедуру?

Я надеюсь найти полезную информацию «под капотом», которую было трудно найти при поиске в этой теме, но я действительно приветствую все комментарии и ответы.

Answer 1

По моему мнению, хранимые процедуры должны использоваться исключительно для манипулирования данными, когда одна и та же подпрограмма должна использоваться в нескольких разных приложениях или для ETL между базами данных или таблицами, и не более того. В основном, делайте как можно больше в коде, пока не столкнетесь с принципом СУХОГО или пока вы просто перемещаете данные из одного места в другое в БД.

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

Answer 2

Я использую представления для нормализации или форматирования вывода и хранимые процедуры для фильтрации и манипулирования данными (вещи, которые требуют ввода параметров) или итерации (курсоры).

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

Answer 3

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

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

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

Answer 4

Не уверен, что это или / или выбор. Хранимые процедуры могут делать самые разные вещи, с которыми столкнутся представления (например, заполнить данные во временной таблице, затем навести на них курсор, а затем выполнить агрегирование и вернуть набор результатов).

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

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