Сохраненный Procs - Лучший способ пасовать назад сообщения к пользовательскому приложению

Мои богохульные 2 цента:

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

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

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

Если это не может проверяться/ловиться ранее, могло бы быть трудно сделать что-либо еще.

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

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

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

Необходимо использовать выходные параметры хранимой процедуры SQL.

Из http://msdn.microsoft.com/en-us/library/ms378108.aspx:

CREATE PROCEDURE GetImmediateManager
   @employeeID INT,
   @msg varchar(50) OUTPUT
AS
BEGIN
   SELECT ManagerID 
   FROM HumanResources.Employee 
   WHERE EmployeeID = @employeeID

   SELECT @msg = 'here is my message'
END

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

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

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

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

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

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

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

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

Первое, что пришло на ум, если Вы действительно возражаете против RAISERROR.

Я использовал бы Возвращаемое значение из хранимой процедуры, как это:

CREATE PROCEDURE checkReturnValue
AS
BEGIN
    DECLARE @err AS INT
    SET @err = 0

    IF (rand() < 0.5)
    BEGIN
        SET @err = 1
    END

    SELECT * FROM table

    PRINT @err

    RETURN @err
END

Проверьте Возвращаемое значение в свое приложение, назвав хранимую процедуру.

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

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

Попытайтесь использовать возвращаемое значение или выходную переменную, если это не достаточно.

Я использовал raiseerror для возврата из глубин нескольких вложенных хранимых процедур, но последний слой хранимой процедуры всегда ловит исключение до того, чтобы быть повышенным до языка вызова (в нашем Java случая через JDBC). Выгода хранимой процедуры во внешнем, большая часть слоя преобразовывается в сообщение XML, которое будет транспортироваться к вызову JDBC и корневому элементу, в соответствии с нашей конвенцией, должна содержать атрибут обратной связи. Значение атрибута обратной связи всегда имеет декоратора или хорошо, предупреждение или ошибка. Хорошо средства продолжаются, ничто для наблюдения здесь. Аварийные средства продолжаются, но показывают остальную часть обратной связи пользователю. Ошибочная плоскодонка средств, назовите справочную службу.

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

Избегайте использования исключений, кроме

1. Исключительная ситуация
2. У вас нет логики обработки исключительной ситуации.

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

Это плохой тон - отвечать на такой старый вопрос? Anywho ...

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