Проблема сериализации хранимых процедур - PullRequest
1 голос
/ 20 января 2009

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

Процедура имеет три оператора sql вместе, как 1. Обновление состояния оборудования в таблице размещения 2. Вычисление следующего соответствующего значения первичного ключа для новой записи, которая будет вставлена ​​в таблицу DEFECT_LOG 3. Вставка значений в таблицу DEFECT_LOG. Я также использую переменную для возврата 1, если транзакция прошла успешно.

ALTER PROCEDURE spCreateDefective

(

    @alloc_ID nvarchar(50),
    @cur_date datetime,
    @problem_desc nvarchar(MAX),
    @got_defect_date datetime,
    @trans_status tinyint OUTPUT --Used to check transaction status
)

AS

/*  Transaction Maintainer Statements   */

BEGIN TRAN transac1

    SET XACT_ABORT ON

    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

/*  Declaration Area    */

    DECLARE @temp nvarchar(10)

    DECLARE @def_ID nvarchar(20)

/*  Updating Inventory Status to 'Defective' and Updating Release Date to current System date   */  

    UPDATE INV_Allocation_DB

    SET INV_STATUS = 'Defective' , RELEASE_DATE=@cur_date
    WHERE INV_ID=@alloc_ID


/*  Calculates New Primary Key for the DEFECT_LOG Table */

--  Returns the largest number or 1 if no records are present in the table  

    SELECT @temp=COALESCE(CONVERT(int,SUBSTRING(MAX(DEFECT_ID),5,5))+1,1) FROM DEFECT_LOG


    SET @def_ID = 'DEF_'+ RIGHT(replicate('0',5)+ convert(varchar(5),@temp),5)

/*  Insert statement for inserting data into DEFECT_LOG */

    INSERT INTO DEFECT_LOG (DEFECT_ID,INV_ID,PROB_DESC,GOT_DEFECT_DATE) 
    VALUES(@def_ID,@alloc_ID,@problem_desc,@got_defect_date)


    SET @trans_status = 1

    COMMIT TRAN transac1

/*  Returns 1 if transaction successful */

RETURN @trans_status

Ответы [ 3 ]

2 голосов
/ 20 января 2009

Использование уровня транзакции SERIALIZABLE не рекомендуется, если только у вас нет необходимости. Это увеличит вероятность блокировки и уменьшит пропускную способность.

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

1 голос
/ 20 января 2009

Лично я бы использовал поле IDENTITY в качестве истинного первичного ключа, но затем имел бы дополнительный столбец с буквенно-цифровым идентификатором. (Возможно, как постоянное вычисляемое поле)

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

0 голосов
/ 20 января 2009

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

...