Сохраненные Запросы?

Question

Считается ли ненормальным хранение общих запросов SQL для моего веб-приложения в базе данных для использования при исполнении? Или это обычная практика? Или это невозможно?

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

Это безумие? Это и есть хранимая процедура? Или это что-то еще?

---

РЕДАКТИРОВАТЬ: ответы ниже полезны в качестве фона для «хранимых процедур», но не ответили на мой основной вопрос: «Хранимая процедура» - это только когда у меня есть таблица базы данных, которая содержит запросы, которые можно вызвать? то есть как то

INDEX | NAME          | QUERY
1     | show_names    | "SELECT names.first, names.last FROM names;"
2     | show_5_cities | "SELECT cities.city FROM cities LIMIT 0,5;"
etc.

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

Answer 1

Наряду с серьезными причинами использования MUG4N хранимых процедур, есть еще три:

Безопасность

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

Подумайте о защите глубоко. Если ваше приложение взломано, то оно будет ограничено выполнением ТОЛЬКО процедур, которые вы определили. Это означает, что такие вещи, как «удаление таблицы», будут явно запрещены, если, конечно, у вас нет процедуры для этого.

И наоборот, если ваше приложение взломано и вы разрешаете приложению иметь полный доступ к вашему серверу sql, то произойдет одно из двух. Либо ваши данные исчезают, и / или взломщик легко получает копию.

---

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

---

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

Answer 2

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

Поскольку кажется, что вы движетесь по маршруту PHP / MySQL, я приведу несколько примеров моего опыта работы с хранимыми процессами в MySQL:

• Они, как правило, гораздо менее читабельны и гораздо сложнее писать, чем PHP.
• Они делают отладку кошмаром
  • Попытка выяснить, почему изменение значения в table_1 вызывает изменение в table_2 (если вам даже повезло осознать, что это происходит), определить гораздо сложнее, просматривая десятки хранимых процедур, чем это делается, скажем, посмотрите на Model , которая обрабатывает изменения в table_1.
• Насколько мне известно, не существует стандартизированного и автоматизированного способа интеграции хранимых процедур / триггеров / и т. Д. В любую систему контроля версий

Answer 3

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

Вот только два преимущества использования хранимых процедур:

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

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

Answer 4

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

Как только приложение разработано, все начинают делать свои реализации, сотрудники БД предоставляют другим какой-то API-интерфейс для использования в скрытии SQL, разработчикам не придется думать об этом и сосредоточиться на своем коде. работал разработчиком БД и использовал некоторые COM-методы для преодоления расширения и модификации логики или повторного использования приложения. База данных в таких продуктах слишком важна, чтобы оставлять ее в дикой природе, поэтому безопасность - это действительно серьезная проблема.

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

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

Answer 5

Хранимая процедура - это просто один или несколько операторов SQL, которые «предварительно скомпилированы» и находятся внутри базы данных. Вы вызываете их для возврата одной или нескольких строк данных или для обновления, вставки или удаления данных.

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

Вы также можете рассмотреть возможность использования инфраструктуры ORM, такой как Hibernate. Это позволит вам полностью отказаться от работы с кодом SQL. Я разработчик .Net, поэтому я не уверен, что вам доступно на платформе PHP / MySQL, но я уверен, что есть из чего выбирать.