Insert con campo autonumerico

27/05/2009 - 05:07 por Penta | Informe spam

Estimados.
Utilizo SS2000
Estabamos realizando una prueba, con una tabla llamada TEST
ID autonumerico (con incremento de 1)
Campo1 Int
Campo2 Int
Total Int (Campos Calculado de Campo1+Campo2)

Aca 2 consultas:
1.- Realizamos un bucle que llenara la tabla con 1 Millon de
registros.
Insert Into TEST (1000,500)
Por algun motivo al terminar el ultimo valor de Id es de 2135000
claramente se salto muchisimos ID, no veo ninguna relacion en cuanto a
cuando y donde salto, pues de 197.000 salto a 350.000 y otros saltos
raros.
Paraleo a esto en otra ventana de Qry Analyzer ibamos haciendo
Select * from TEST
Cual sería el motivo de dichos saltos??

2.- Bueno el ID me da lo mismo para a idea original ya que era para
comprobar el tiempo de ejecucion de la misma consulta de la tabla TEST
con un campo calculado (Total) y un campo Total que no sea calculado
(es decir que tenga el update de campo1+campo2) esto lo hicimos con
TEST2 y el campo TOTAL lo indexamos.

Select * from TEST (sin indices)
Where total > 500

Select * from TEST2
Where total > 500

2.1.- Se demoran lo mismo.
2.2.- Al revisar el plan de ejecucion de la consulta de TEST2 no usa
el indice creado para dicho efecto mas bien usa la PK del Id

Pregunta aparte:
En una consulta acá mismo me dijeron que el tener un campo con los
valores ya calculados (TEST2)me servia en caso de querer filtrar por
dicho campo ya que lo podia indexar, no pude comprobar eso, ademas
entendi con dicha argumentacion que un campo calculado NO lo podia
indexar pero SI pude hacerlo (TEST)

Atte.
PENTA.

Siga el debate

3 respuestas

Tengo una respuesta

Preguntas similare

Problemas al realizar Bulk Insert con Campo de Fechas favor ayuda urgente

Leer las respuestas

#1 Carlos Sacristan

27/05/2009 - 08:33 | Informe spam

Por partes:

No sé por qué te puede estar pasando esos saltos, yo crearía la tabla de
nuevo y ejecutaría el proceso otra vez con una traza de profiler por si se
estuviera haciendo algo mal. También habría que ver cómo estáis ejecutando
dicho proceso.

En cuanto a lo de que el plan y el tiempo de ejecución sea el mismo, si
insertas los mismos valores, es normal que SQL Server opte por recorrerse la
tabla en vez de usar el índice. Prueba a meter valores aleatorios, o con una
distribución que te permita comprobar la diferencia entre usar el índice o
no hacerlo.

Creo recordar que fui yo el que te contestó lo de usar campos calculados,
pero en ningún momento te dije que no se pudiera indexar, más bien todo lo
contrario.

Un saludo
-
www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

"Penta" escribió en el mensaje
news:
Estimados.
Utilizo SS2000
Estabamos realizando una prueba, con una tabla llamada TEST
ID autonumerico (con incremento de 1)
Campo1 Int
Campo2 Int
Total Int (Campos Calculado de Campo1+Campo2)

Aca 2 consultas:
1.- Realizamos un bucle que llenara la tabla con 1 Millon de
registros.
Insert Into TEST (1000,500)
Por algun motivo al terminar el ultimo valor de Id es de 2135000
claramente se salto muchisimos ID, no veo ninguna relacion en cuanto a
cuando y donde salto, pues de 197.000 salto a 350.000 y otros saltos
raros.
Paraleo a esto en otra ventana de Qry Analyzer ibamos haciendo
Select * from TEST
Cual sería el motivo de dichos saltos??

2.- Bueno el ID me da lo mismo para a idea original ya que era para
comprobar el tiempo de ejecucion de la misma consulta de la tabla TEST
con un campo calculado (Total) y un campo Total que no sea calculado
(es decir que tenga el update de campo1+campo2) esto lo hicimos con
TEST2 y el campo TOTAL lo indexamos.

Select * from TEST (sin indices)
Where total > 500

Select * from TEST2
Where total > 500

2.1.- Se demoran lo mismo.
2.2.- Al revisar el plan de ejecucion de la consulta de TEST2 no usa
el indice creado para dicho efecto mas bien usa la PK del Id

Pregunta aparte:
En una consulta acá mismo me dijeron que el tener un campo con los
valores ya calculados (TEST2)me servia en caso de querer filtrar por
dicho campo ya que lo podia indexar, no pude comprobar eso, ademas
entendi con dicha argumentacion que un campo calculado NO lo podia
indexar pero SI pude hacerlo (TEST)

Atte.
PENTA.

Responder a este mensaje

#2 Penta

27/05/2009 - 19:48 | Informe spam

On 27 mayo, 02:33, "Carlos Sacristan" wrote:

Por partes:

No sé por qué te puede estar pasando esos saltos, yo crearía la tabla de
nuevo y ejecutaría el proceso otra vez con una traza de profiler por si se
estuviera haciendo algo mal. También habría que ver cómo estáis ejecutando
dicho proceso.

En cuanto a lo de que el plan y el tiempo de ejecución sea el mismo, si
insertas los mismos valores, es normal que SQL Server opte por recorrerse la
tabla en vez de usar el índice. Prueba a meter valores aleatorios, o con una
distribución que te permita comprobar la diferencia entre usar el índice o
no hacerlo.

Creo recordar que fui yo el que te contestó lo de usar campos calculados,
pero en ningún momento te dije que no se pudiera indexar, más bien todo lo
contrario.

Un saludo
-www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

Estimado Carlos.
Muchas gracias por tus respuestas, y claro tienes toda la razón en
cuanto a t comentario sobre indexar un campo calculado, al leer tu
respuesta fuí YO el que lo entendió de esa manera.
Lo de los indices del campo con el update o calculado lo probaré, pero
me quedo con la sensación con el campo calculado de como SI lo puedo
indexar es la mejor alternativa en comparación a tener un campo
updateado, o existe alguna variante al respecto ?

Sobre los id, ni modo, el bucle es bastante sencillo, asi que lo
dejare para cuando tenga un tiempo, por acá leí que los identy no
aseguraban la correlación, solo aseguraban el campo unico.

Saludos y gracias nuevamente.
PENTA.

Responder a este mensaje

#3 Carlos Sacristan

28/05/2009 - 08:47 | Informe spam

No, a ver. Lo que no aseguran los identity es que no existan saltos, ya
que no es transaccional. Por ejemplo, si abres una transacción y la
cancelas, ese número no se recupera.

Yo no me molestaría en probar entre el campo calculado o que el cálculo
lo hagas tú y luego actualices. Los campos calculados se crearon justamente
para evitar esas operaciones, pero como tú veas. Nunca está de más probar
las cosas. Lo que sí que te comenté en su momento es que si no vas a hacer
ninguna operación con ese campo (filtrar por él), no te merece la pena
tenerlo en la base de datos, sino hacer ese cálculo en la aplicación cliente
en donde vayas a mostrar la información.

Un saludo
-
www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

"Penta" escribió en el mensaje
news:
On 27 mayo, 02:33, "Carlos Sacristan" wrote:

Por partes:

No sé por qué te puede estar pasando esos saltos, yo crearía la tabla de
nuevo y ejecutaría el proceso otra vez con una traza de profiler por si se
estuviera haciendo algo mal. También habría que ver cómo estáis ejecutando
dicho proceso.

En cuanto a lo de que el plan y el tiempo de ejecución sea el mismo, si
insertas los mismos valores, es normal que SQL Server opte por recorrerse
la
tabla en vez de usar el índice. Prueba a meter valores aleatorios, o con
una
distribución que te permita comprobar la diferencia entre usar el índice o
no hacerlo.

Creo recordar que fui yo el que te contestó lo de usar campos calculados,
pero en ningún momento te dije que no se pudiera indexar, más bien todo lo
contrario.

Un saludo
-www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

Busqueda sugerida