SELECT INTO или хранимая процедура?

Question

Будет ли это лучше как хранимая процедура или оставить ее как есть?

INSERT INTO `user_permissions` 
    (`user_id`, `object_id`, `type`, `view`, `add`, `edit`, `delete`, `admin`, `updated_by_user_id`) 
    SELECT `user_id`, $object_id, '$type', 1, 1, 1, 1, 1, $user_id 
    FROM `user_permissions` 
    WHERE `object_id` = $object_id_2 AND `type` = '$type_2' AND `admin` = 1 

Вы можете думать об этом с разными объектами, скажем, у вас есть группы и подгруппы. Если кто-то создает подгруппу, то все, кто имел доступ к родительской группе, теперь имеют доступ к подгруппе.

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

Должен ли я создавать процедуру или производительность будет несущественной?

Answer 1

Материал из Википедии Stored Procedure:

Накладные: Поскольку хранимые заявления процедура хранятся непосредственно в базе данных , это может удалить все или часть компиляции накладных расходов, которые обычно требуется в тех случаях, когда это прикладные программы отправить inline (динамический) SQL-запросы к базе данных. (Тем не менее, большинство систем баз данных реализовать «заявление кэшей» и другие механизмов, чтобы избежать повторных компиляции динамических SQL утверждений.) Кроме того, предварительно скомпилированные заявления SQL, избегая при этом некоторые накладных расходов, добавить к сложности , создавая оптимальный план выполнения , поскольку не все аргументы инструкции SQL поставляются на этапе компиляции . В зависимости от конкретной реализации базы данных и конфигурации , смешанная производительность результаты будут получены из сохраненных процедур или общих запросов или пользовательских функций.

Избежания сетевого трафика: Основной преимущество хранимых процедур является , что они могут работать непосредственно в двигателе базы данных. В системе это обычно означает, что процедуры полностью выполняются на специализированном сервере базы данных , который имеет прямой доступ к данным, находящимся в . Преимущество здесь в том, что расходы на связь могут быть полностью исключены . Это становится особенно важным для сложных операторов SQL.

Инкапсуляция бизнес-логики: Хранимые процедуры позволяют для бизнеса логики вкладывается в качестве API в базе , которая может упростить ДАННЫЕ управления и уменьшить необходимость кодирования логики в другом месте в клиенте программы , Это может привести к снижению вероятности повреждения данных с использованием неисправного клиента . Таким образом, система базы данных может обеспечить целостность данных и согласование с помощью сохраненных процедур .

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

Некоторые защиты от SQL инъекций атаки: Хранимые процедуры могут быть использованы для защиты от этой атаки. Параметры будут обрабатываться как данные , даже если злоумышленник вставляет команды SQL . Также некоторые СУБД будут проверять тип параметра .

Недостатки

Хранимые процедуры "определяется один раз, использовать много раз." Если какие-либо изменения необходимы , необходимо заменить (1 и только один) определение хранимой процедуры . Динамический SQL, Конечно, позволяет любой запрос SQL быть выпущен в любое время. Любое изменение хранимой процедуры мгновенно воздействует на каждый другой программный продукт, отчет, и т. Д. (Внутри или за пределами СУБД) , который прямо или косвенно ссылается на . Не всегда возможно, чтобы точно определял то, что будет иметь эти удары, а также то, что можно сделать без изменений без , что отрицательно скажется на чем-то другом.

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

Хотя не имеет прямое отношение к хранимым процедур, движение бизнеса логики к СУБД является проблематичным, поскольку это слой с более сложными вопросами масштабируемости. Кроме того, некоторые современные системы СУБД (в частности, из Microsoft SQL Server 2000 и выше) не предлагают какую-либо производительность преимущества использования хранимых процедур против скомпилированных запросов: они составляются и кэшируются в том же порядке, как динамического SQL.

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