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

Question

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

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

Является ли это сумасшедшим? Это что такое хранимая процедура? Или это что-то еще?

---

EDIT: Приведенные ниже ответы полезны в качестве фона для «хранимых процедур», но не ответил на мой основной вопрос: Является ли «хранимая процедура» только тогда, когда у меня есть таблица базы данных, которая содержит запросы, которые могут называться? т.е. что-то вроде этого

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 о том, почему использовать хранимые процедуры, вот еще три:

безопасности

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

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

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

---

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

---

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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