Проблема сериализации хранимых процедур

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

Процедура содержит три оператора 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

🤔 А знаете ли вы, что...
SQL Server поддерживает хранение и обработку больших объемов данных, включая поддержку столбцового хранилища (columnstore) для аналитических запросов.


1
2 007
2

Ответы:

Решено

Не рекомендуется использовать СЕРИАЛИЗИРУЕМЫЙ уровень транзакции, если он вам не нужен. Это увеличит вероятность блокировки и снизит пропускную способность.

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


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

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