Хранимая процедура для всего

Question

У меня была горячая дискуссия с коллегой по использованию хранимых процедур (SP) в приложении .NET (в базе данных SQL Server 2005). [У него есть опыт работы в Microsoft, а у меня Java - что может быть или не быть актуальным].

Я должен вставить данные, полученные в пользовательском интерфейсе. Для этого я бы написал SP и использовал бы его в коде .NET? Это не обязательно, но каковы плюсы и минусы использования SP?

Другой сценарий:

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

1. В моем коде запустите запрос на выборку, чтобы проверить, существует ли он, а затем, если нет, введите город, иначе ошибка в интерфейсе пользователя.
2. Вставить напрямую и благодаря уникальному индексу SQLException будет пойман. Просмотрите SQLException, чтобы проверить, какой уникальный индекс нарушен, и покажите соответствующую ошибку.
3. создать один SP и обработать указанную выше логику, то есть проверить наличие дубликатов и выдать ошибку или вставить

Какой из них правильный путь? (ссылки на хорошие ресурсы приветствуются).

Answer 1

Во-первых, рекомендуется использовать SP, а не специальные операторы SQL, потому что: 1) безопасность - нужно только дать разрешение на выполнение sproc, а не на базовые таблицы 2) ремонтопригодность - может исправлять SP в SQL Server без необходимости перестраивать / развертывать код .NET для настройки запроса 3) производительность - кэширование / повторное использование плана выполнения при использовании sprocs повышает производительность (может быть сделано также при использовании параметризованного SQL напрямую в .NET) 4) сетевой трафик (нормально, незначительно, но SP спасут вас, передавая весь оператор SQL по сети, особенно если большой запрос)

Исключения обходятся дорого, поэтому старайтесь не создавать исключений, когда это можно предотвратить. Я бы порекомендовал написать sproc, который выполняет проверку IF EXISTS, прежде чем пытаться вставлять запись и вставлять ее, только если она не существует. Просто верните код возврата или выходной параметр, указывающий, что произошло. например 0 = вставлено ОК, -1 = уже существует

Сделайте все это в течение одного вызова sproc, чтобы сохранить циклические обходы БД (т.е. не запрашивайте сначала БД для проверки, а затем отправьте другой оператор для выполнения INSERT). Использование проверки EXISTS является наиболее оптимальным способом проверки.

Answer 2

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

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

Но, как и во всех эмпирических правилах, всегда есть исключения.

Answer 3

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

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

С наилучшими пожеланиями

Answer 4

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

Answer 5

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

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

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

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

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

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

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