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

Question

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

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

Answer 1

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

Если они на самом деле "ошибки", у меня нет особых проблем с этим. Если он вставляет запись и использует RAISERROR для выброса («Вы успешно зарегистрировались в XYZ!»), Значит, у вас проблема. Если бы это было так, я бы, вероятно, придумал стандарт развития команды / отдела / компании для использования параметров.

Answer 2

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

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

Answer 3

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

Answer 4

Исключения следует выдавать только тогда, когда ситуация исключительная, и у вас нет логики обработки. Также повышение и ловля исключение дорого.

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

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

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

Answer 5

Плохо ли отвечать на этот старый вопрос? Anywho ...

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

Answer 6

Вы должны использовать выходные параметры хранимой процедуры 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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

Проверьте значение ВОЗВРАТА в вашем приложении, вызвав хранимую процедуру.

Answer 10

Для возврата из глубины нескольких вложенных хранимых процедур я использовал повышение в памяти, но последний уровень хранимой процедуры всегда перехватывает исключение перед возвратом в язык вызова (в нашем случае Java через JDBC). Перехват хранимой процедуры в самом внешнем слое преобразуется в сообщение XML для переноса в вызов JDBC, и корневой элемент, согласно нашему соглашению, должен содержать атрибут обратной связи. Значение атрибута обратной связи всегда имеет декоратор ok, alert или error. Ок, значит, продолжай, здесь ничего не видно. Оповещение означает «продолжай, но покажи остальную часть обратной связи пользователю». Ошибка означает «пунт», позвоните в службу поддержки.