Insertar proceso almacenado de actualización en SQL Server

Question

He escrito un proceso almacenado que hará una actualización si existe un registro, de lo contrario, hará una inserción. Se ve algo como esto:

update myTable set Col1=@col1, Col2=@col2 where ID=@ID 
if @@rowcount = 0 
insert into myTable (Col1, Col2) values (@col1, @col2) 

Mi lógica detrás de escribir de esta manera es que la actualización se realice una implícita seleccione mediante la cláusula dónde y si devuelve 0, entonces el inserto se llevará a cabo.

La alternativa para hacerlo de esta manera sería hacer una selección y luego, en función del número de filas devueltas, realice una actualización o inserte. Esto lo considero ineficiente porque si va a hacer una actualización, causará 2 selecciones (la primera llamada de selección explícita y la segunda implícita en el lugar de la actualización). Si el proceso fuera a hacer una inserción, entonces no habría diferencia en la eficiencia.

¿Mi lógica suena aquí? ¿Es así como combinaría una inserción y una actualización en un proceso almacenado?

Answer 1

Su suposición es correcta, esta es la forma óptima de hacerlo y se llama upsert/merge.

Importance of UPSERT - from sqlservercentral.com:

Por cada actualización en el caso mencionado anteriormente vamos a eliminar uno lectura adicional de la tabla si utilizamos el lugar de UPSERT existe. Desafortunadamente para un inserto, tanto el métodoUPSERT como el IF EXISTS usan el mismo número de lecturas en la tabla . Por lo tanto, la comprobación de existencia solo debe realizarse cuando existe un motivo muy válido para justificar la E/S adicional . La forma optimizada para hacer las cosas es asegurarse de que tenga pocas lecturas como sea posible en el DB.

La mejor estrategia es intentar la actualización . Si ninguna fila se ve afectada por la actualización , inserte. En la mayoría de las circunstancias , la fila ya habrá y solo se requerirá una E/S .

Editar: Por favor, echa un vistazo a this answer y la entrada de blog vinculado a aprender acerca de los problemas con este patrón y cómo hacer que funcione segura.

Answer 2

Por cierto, MERGE es una de las características nuevas de SQL Server 2008.

Answer 3

Si se va a utilizar con SQL Server 2000/2005, el código original debe incluirse en la transacción para asegurarse de que los datos permanecen constantes en el escenario concurrente.

BEGIN TRANSACTION Upsert 
update myTable set Col1=@col1, Col2=@col2 where ID=@ID 
if @@rowcount = 0 
insert into myTable (Col1, Col2) values (@col1, @col2) 
COMMIT TRANSACTION Upsert 

Esto tendrá un costo de rendimiento adicional, pero garantizará la integridad de los datos.

Agregue, como ya se ha sugerido, MERGE debería usarse donde esté disponible.

Answer 4

Gran admirador de UPSERT, realmente reduce el código para administrar. Aquí hay otra forma en que lo hago: uno de los parámetros de entrada es ID, si el ID es NULL o 0, usted sabe que es un INSERT, de lo contrario es una actualización.Asume que la aplicación sabe si hay una identificación, por lo que no funcionará en todas las situaciones, pero cortará los ejecutables a la mitad si lo hace.

Answer 5

Su lógica parece sólida, pero es posible que desee considerar agregar algún código para evitar la inserción si hubiera pasado una clave primaria específica.

De lo contrario, si siempre está haciendo una inserción si la actualización no afectó ningún registro, ¿qué sucede cuando alguien borra el registro antes de ejecutar "UPSERT"? Ahora el registro que intentabas actualizar no existe, por lo que creará un registro. Ese probablemente no es el comportamiento que estabas buscando.

Answer 6

Si usted no está haciendo una mezcla en SQL 2008, debe cambiarlo a:

si @@ recuento de filas = 0 y @@ error = 0

de lo contrario si la actualización falla por alguna razón, entonces lo intentará y luego lo insertará porque el recuento de filas en una declaración fallida es 0

Answer 7

No solo necesita ejecutarlo en una transacción, sino que también necesita un alto nivel de aislamiento. De hecho, el nivel de aislamiento predeterminado es Read Commited y este código necesita Serializable.

SET transaction isolation level SERIALIZABLE 
BEGIN TRANSACTION Upsert 
UPDATE myTable set Col1=@col1, Col2=@col2 where ID=@ID 
if @@rowcount = 0 
    begin 
    INSERT into myTable (ID, Col1, Col2) values (@ID @col1, @col2) 
    end 
COMMIT TRANSACTION Upsert 

Quizás agregar también la comprobación @@ error y la reversión sean una buena idea.

Answer 8

Lea el post on my blog para obtener un patrón bueno y seguro que puede usar. Hay muchas consideraciones, y la respuesta aceptada sobre esta cuestión está lejos de ser segura.

Para obtener una respuesta rápida, pruebe el siguiente patrón. Funcionará bien en SQL 2000 y superior. SQL 2005 le proporciona un manejo de errores que abre otras opciones y SQL 2008 le da un comando MERGE.

begin tran 
    update t with (serializable) 
    set hitCount = hitCount + 1 
    where pk = @id 
    if @@rowcount = 0 
    begin 
     insert t (pk, hitCount) 
     values (@id,1) 
    end 
commit tran 

Answer 9

Modificado posterior Dima Malenko:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 

BEGIN TRANSACTION UPSERT 

UPDATE MYTABLE 
SET COL1 = @col1, 
     COL2 = @col2 
WHERE ID = @ID 

IF @@rowcount = 0 
    BEGIN 
     INSERT INTO MYTABLE 
        (ID, 
        COL1, 
        COL2) 
     VALUES  (@ID, 
        @col1, 
        @col2) 
    END 

IF @@Error > 0 
    BEGIN 
     INSERT INTO MYERRORTABLE 
        (ID, 
        COL1, 
        COL2) 
     VALUES  (@ID, 
        @col1, 
        @col2) 
    END 

COMMIT TRANSACTION UPSERT 

Puede interceptar el error y enviar el registro a una tabla de inserción fallado.
Necesito hacer esto porque estamos tomando cualquier información que se envíe a través de WSDL y, si es posible, solucionándola internamente.