Хранимые процедуры или встроенные запросы?

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

Смотрите здесь: Каковы плюсы и минусы хранения SQL в хранимых процедурах по сравнению с кодом и здесь SubSonic и хранимые процедуры

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

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

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

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

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

2 / Хранимые процедуры могут содержать логику, которую лучше оставить в базе данных. Я видел хранимые процессы в DB2 / z с множеством десятков строк, но все, что клиент должен кодировать, - это одна строка вроде «дай мне этот список».

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

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

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

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

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

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

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

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

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

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

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

Вас вообще беспокоит безопасность вашей базы данных?

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

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

Я предпочитаю встроенный sql, если хранимая процедура не имеет реальной логики (переменных, курсоров и т. д.). В последнее время я использую LINQ to SQL и беру сгенерированные классы и добавляя частичные классы, которые имеют некоторые предопределенные общие запросы linq. Я считаю, что это способствует более быстрому развитию.

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

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

Для основных операций CRUD встроенный SQL будет прямым. Для более сложных данных необходимо создать представление, а затем выполнить запрос Subsonic в представлении.

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

Текущее приложение Subsonic использует все три варианта с отличными результатами.

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

2. Хранимые процедуры могут содержать логику, которую лучше оставить в базе данных. Я видел хранимые процессы в DB2 / z с множеством десятков строк, но все, что клиент должен кодировать, - это одна строка вроде «дай мне этот список».

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

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

Преимущества хранимой процедуры (на мой взгляд)

1. SQL в одном месте
2. Вы можете получить планы запроса.
3. При необходимости вы можете изменить структуру базы данных для повышения производительности.
4. Они компилируются, и, следовательно, эти планы запросов не нужно создавать на лету.
5. Если вы используете разрешения - можете быть уверены в запросах, которые будет делать приложение.