Duda para evitar duplicados.

Yo prefiero recuperarme del error cuando las claves son naturales, si son no
naturales, entonces pongo un autonumérico y generalmente no hay problemas.
Creo peersonalmente que es buena idea basarse en las reglas de la propia
BBDD
-

Miguel Egea Gómez
Webmaster de PortalSQL

(lo de online sobra)

Microsoft SqlServer M.V.P.


"Carmelo J. Morales Muñoz" escribió en el mensaje
news:f6ppc.214627$

¡Hola!

¿que es mejor forma de evitar duplicados?. Gestionar en el propio
StoreProc de inserción si ya existe? Esperar a que de error las reglas
de integridad?...

Gracias!

Hola, yo no lo hago en el Store porque para poder hacer eso dbes buscar
primero el valor en la tabla y esto genera Bloqueos y un paso de mas que no
le veo sentido.

Me explico?

Suerte


Salu2

Maxi

Desarrollador 3 estrellas .NET
Buenos Aires - Argentina

MSN:

"Carmelo J. Morales Muñoz" escribió en el mensaje
news:f6ppc.214627$

¡Hola!

¿que es mejor forma de evitar duplicados?. Gestionar en el propio
StoreProc de inserción si ya existe? Esperar a que de error las reglas
de integridad?...

Gracias!

Hola:
Desde el punto de vista de mantenimiento de codigo es mejor insertar y
revisar el error.
Desde el punto de vista de desempeno lo mejor es revisar antes y si no
existe iniciar la transaccion insertar y por ultimo controlar que no hubo
error. Este patron es:
=IF EXISTS(...)
BEGIN
RAISERROR(...)
END
IF EXISTS(..)
BEGING
RAISERROR(...)
END

BEGIN TRAN
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
EDN
COMMIT
= Es muy rapido, porque evita la transaccion en la gran mayoria de los
casos. y cuando la realiza es muy poco probable que tenga error.
La desventaja es que tienes que escribir la regla 2 veces!!! en el
CHECK/PRIMARY KEY/FOREIGN KEY, y en el IF EXISTS, y a pesar de esto puede
ocurrir un error.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Carmelo J. Morales Muñoz escribio:

¡Hola!

¿que es mejor forma de evitar duplicados?. Gestionar en el propio
StoreProc de inserción si ya existe? Esperar a que de error las
reglas de integridad?...

Gracias!

jeje, hombre prevenido vale por dos :-)


-

Miguel Egea Gómez
Webmaster de PortalSQL

(lo de online sobra)

Microsoft SqlServer M.V.P.

"Javier Loria" escribió en el mensaje
news:

Hola:
Desde el punto de vista de mantenimiento de codigo es mejor insertar y
revisar el error.
Desde el punto de vista de desempeno lo mejor es revisar antes y si no
existe iniciar la transaccion insertar y por ultimo controlar que no hubo
error. Este patron es:
=> IF EXISTS(...)
BEGIN
RAISERROR(...)
END
IF EXISTS(..)
BEGING
RAISERROR(...)
END

BEGIN TRAN
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
EDN
COMMIT
=> Es muy rapido, porque evita la transaccion en la gran mayoria de los
casos. y cuando la realiza es muy poco probable que tenga error.
La desventaja es que tienes que escribir la regla 2 veces!!! en el
CHECK/PRIMARY KEY/FOREIGN KEY, y en el IF EXISTS, y a pesar de esto puede
ocurrir un error.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Carmelo J. Morales Muñoz escribio:
> ¡Hola!
>
> ¿que es mejor forma de evitar duplicados?. Gestionar en el propio
> StoreProc de inserción si ya existe? Esperar a que de error las
> reglas de integridad?...
>
> Gracias!

Hola:
Asi es. En realidad ese patron de codigo que tan LARGO y tan FEO, es lo
que se requiere para evitar una vulnerabilidad llamada TOCTTOU (Time of
Check to Time of Use), que en el caso de SQL se puede utilizar para hacer un
DOS (Deny of Service).
Una vulnerabilidad TocTTou ocurre cuando en la aplicacion ocurre algun
lapso entre el checkeo y el uso, por ejemplo en la capa de negocios reviso
que no exista la llave. Desde la validacion hasta el uso de la regla la
aplicacion es suceptible a ataque. En el caso de SQL significa que puedo
provocar que se genere la misma llave, obligando al SQL a hacer rollbacks
frecuentes, que tienen un costo en desempeno muy alto.
Entonces si monitoreo el cable, veo que la aplicacion esta mandando una
solicitud para una llave y en la aplicacion que ataca, envio la misma llave
al SQL, fuerzo los Rollbacks. Si la hago bastante veces eventualmente se les
negara el acceso a otros usuarios, por TimeOut logrando el DOS :(
Dos formas de reducir la exposicion al TocTou son incrementar los
chequeos y hacerlos lo mas cercanos posibles al uso.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Miguel Egea escribio:

jeje, hombre prevenido vale por dos :-)



"Javier Loria" escribió en el mensaje
news:

Hola:
Desde el punto de vista de mantenimiento de codigo es mejor
insertar y revisar el error.
Desde el punto de vista de desempeno lo mejor es revisar antes y
si no existe iniciar la transaccion insertar y por ultimo controlar
que no hubo error. Este patron es:
=>> IF EXISTS(...)
BEGIN
RAISERROR(...)
END
IF EXISTS(..)
BEGING
RAISERROR(...)
END

BEGIN TRAN
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
END
INSERT ...

IF @@ERROR <> THEN
BEGIN
RAISERROR(...)
ROLLBACK
RETURN 1
EDN
COMMIT
=>> Es muy rapido, porque evita la transaccion en la gran mayoria de
los casos. y cuando la realiza es muy poco probable que tenga error.
La desventaja es que tienes que escribir la regla 2 veces!!! en
el CHECK/PRIMARY KEY/FOREIGN KEY, y en el IF EXISTS, y a pesar de
esto puede ocurrir un error.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Carmelo J. Morales Muñoz escribio:

¡Hola!

¿que es mejor forma de evitar duplicados?. Gestionar en el
propio StoreProc de inserción si ya existe? Esperar a que de
error las reglas de integridad?...

Gracias!