none
select RRS feed

  • Pregunta

  • Estimados amigos quiero hacer un SELECT, Pero se da el caso que tengo tablas con registros de 60,000 y 80,000 

    Tengo INNER JOIN en el SELECT para ambas tablas pero cuando quiero mostrar los registros dilata en mostrar, hay algunas función o otro tipo de unión de tablas para que la búsqueda no dilate en mostrar los registros en caso que los registros son muchos?


    jueves, 18 de octubre de 2018 19:22

Respuestas

  • Hola Alexander Valle:

    El motor SQL en una consulta, tal cual lo escribes, en dos tablas correctamente relacionadas y con los "deberes hechos", tendría que tardar en resolver, para 60000 y 80000 registros aproximadamente 0 segundos. Y tu equipo, el que tiene el software cliente, por ejemplo en Management Studio, en pintar la resolución entre 1 y 3 segundos.

    Ahora bien, mostrar no es igual que tener.

    La consulta puede ser buenísima, pero para pintartela en la pantalla puede dilatarse mucho, porque tiene infinidad de conlumnas, depende de los requisitos de la máquina, la memoria de video, y yo que se... cuantas cosas que son meramente causísticas propias de cada PC o dispositivo, ya que tiene que, pintar los cuadraditos que envuelven el resultado de cada columna por cada fila. Pueden ser dos caminos bien diferentes.

    Como te ha indicado Hunchback, el camino a recorrer es, si quieres que te podamos ayudar a mejorar esa consulta, caso de que sea necesario, cuanta más información pongas, más posibilidades tienes de que esa posible solución sea fructífera.

    Si en realidad en encargado de mostrar tu información es un software cliente/aplicación que estas desarrollando, y lo estas haciendo con alguna herramienta tipo Visual studio, pon un punto de interrupción entre la petición y la resolución, para ver cual es la demora, no vaya a ser, que estas pensando que el motor tarda y no es el motor, el que se dilata.

    viernes, 19 de octubre de 2018 5:38
  • Hola:

    A lo mejor no fui del todo claro, con la idea, pero la misma, es que si esta "bien construida", 60000 u 80000 registros, no pueden significar una demora grande. Todo depende de muchos factores, porque evidentente no es lo mismo construir algo con dos bytes, que con dos millones de bytes.

    Voy a intentar matizarlo un poco más.

    create table table1 (id int identity (1,1) primary key, numero1 int, numero2 varchar(10))
    go
    create table table2 (id int primary key, descripcion varchar(10))
    go
    declare @num int=0;
    while @num < 80000
    begin
    
    	insert into table1 (numero1, numero2)
    	values (@num, cast(@num as varchar(10)));
    
    	insert into table2 (id, descripcion)
    	 values (@num,cast(@num as varchar(10)));
    
    	 set @num =@num +1;
    end
    go
    /*creo dos tablas relacionadas por un campo para hacer pruebas*/
    
    print convert(nvarchar(30),getdate(),126)
    select t.id, t2.descripcion from table1 t inner join table2 t2 on t.numero1 = t2.id
    print convert(nvarchar(30),getdate(),126)

    Salida:

    Pintar dos columnas con 80000 registros, demora 600 milesimas de segundo en un PC normal.

    Ahora le añado unas columnas de más a la tabla

    alter table table1 
    add campo1 varchar(max),
     campo2 varchar(max),
     campo3 varchar(max),
     campo4 varchar(max),
     campo5 varchar(max),
     càmpo6 varchar(max);
     go
     
     update a set campo1=a.numero2 from table1 a;
     update a set campo2=a.campo1+a.numero2 from table1 a;
     update a set campo3=a.campo2+a.numero2 from table1 a;
     update a set campo4=a.campo3+a.numero2 from table1 a;
     update a set campo5=a.campo4+a.numero2 from table1 a;
     update a set càmpo6=a.campo5+a.numero2 from table1 a;
     go
    
    print convert(nvarchar(30),getdate(),126)
    select t.*, t2.descripcion from table1 t inner join table2 t2 on t.numero1 = t2.id
    print convert(nvarchar(30),getdate(),126)

    Y el mismo escenario tarda en pintar los datos, algo más de un segundo

    Saludos

    sábado, 20 de octubre de 2018 7:54
  • Hola Alexander Valle:

    Si quieres que la ayuda, te pueda ser útil, para la consulta, pégala entera.

    Índica cuales son los índices que dispone cada tabla.

    Cuanta más información aportes, más posibilidades de llegar a aportar algo que solucione tu incidencia.

    martes, 23 de octubre de 2018 19:29

Todas las respuestas

  • Seria de mucha ayuda que postearas la estructura de las tablas, incluyendo restricciones e indices, asi como el plan de ejecucion.



    AMB

    Some guidelines for posting questions...

    AYÚDANOS A AYUDARTE, guía básica de consejos para formular preguntas

    jueves, 18 de octubre de 2018 19:27
  • Hola Alexander Valle:

    El motor SQL en una consulta, tal cual lo escribes, en dos tablas correctamente relacionadas y con los "deberes hechos", tendría que tardar en resolver, para 60000 y 80000 registros aproximadamente 0 segundos. Y tu equipo, el que tiene el software cliente, por ejemplo en Management Studio, en pintar la resolución entre 1 y 3 segundos.

    Ahora bien, mostrar no es igual que tener.

    La consulta puede ser buenísima, pero para pintartela en la pantalla puede dilatarse mucho, porque tiene infinidad de conlumnas, depende de los requisitos de la máquina, la memoria de video, y yo que se... cuantas cosas que son meramente causísticas propias de cada PC o dispositivo, ya que tiene que, pintar los cuadraditos que envuelven el resultado de cada columna por cada fila. Pueden ser dos caminos bien diferentes.

    Como te ha indicado Hunchback, el camino a recorrer es, si quieres que te podamos ayudar a mejorar esa consulta, caso de que sea necesario, cuanta más información pongas, más posibilidades tienes de que esa posible solución sea fructífera.

    Si en realidad en encargado de mostrar tu información es un software cliente/aplicación que estas desarrollando, y lo estas haciendo con alguna herramienta tipo Visual studio, pon un punto de interrupción entre la petición y la resolución, para ver cual es la demora, no vaya a ser, que estas pensando que el motor tarda y no es el motor, el que se dilata.

    viernes, 19 de octubre de 2018 5:38
  • Saludos,

    Lo que comanta Javi es correcto aunque eso de 0, 1 o 3 segundos no se me hace correcto, no sabamos cuantas columnas tenga cada tabla, no sabemos el resultado del join y menos si existen indices optimos y que tipo de campos para determinar un tiempo, en primera te preguntaria porque una aplicación toma 60mil registros como resultado, no me parece correcto.


    Blog: www.sqlservertoolbox.blogspot.com.mx

    viernes, 19 de octubre de 2018 14:31
  • Hola:

    A lo mejor no fui del todo claro, con la idea, pero la misma, es que si esta "bien construida", 60000 u 80000 registros, no pueden significar una demora grande. Todo depende de muchos factores, porque evidentente no es lo mismo construir algo con dos bytes, que con dos millones de bytes.

    Voy a intentar matizarlo un poco más.

    create table table1 (id int identity (1,1) primary key, numero1 int, numero2 varchar(10))
    go
    create table table2 (id int primary key, descripcion varchar(10))
    go
    declare @num int=0;
    while @num < 80000
    begin
    
    	insert into table1 (numero1, numero2)
    	values (@num, cast(@num as varchar(10)));
    
    	insert into table2 (id, descripcion)
    	 values (@num,cast(@num as varchar(10)));
    
    	 set @num =@num +1;
    end
    go
    /*creo dos tablas relacionadas por un campo para hacer pruebas*/
    
    print convert(nvarchar(30),getdate(),126)
    select t.id, t2.descripcion from table1 t inner join table2 t2 on t.numero1 = t2.id
    print convert(nvarchar(30),getdate(),126)

    Salida:

    Pintar dos columnas con 80000 registros, demora 600 milesimas de segundo en un PC normal.

    Ahora le añado unas columnas de más a la tabla

    alter table table1 
    add campo1 varchar(max),
     campo2 varchar(max),
     campo3 varchar(max),
     campo4 varchar(max),
     campo5 varchar(max),
     càmpo6 varchar(max);
     go
     
     update a set campo1=a.numero2 from table1 a;
     update a set campo2=a.campo1+a.numero2 from table1 a;
     update a set campo3=a.campo2+a.numero2 from table1 a;
     update a set campo4=a.campo3+a.numero2 from table1 a;
     update a set campo5=a.campo4+a.numero2 from table1 a;
     update a set càmpo6=a.campo5+a.numero2 from table1 a;
     go
    
    print convert(nvarchar(30),getdate(),126)
    select t.*, t2.descripcion from table1 t inner join table2 t2 on t.numero1 = t2.id
    print convert(nvarchar(30),getdate(),126)

    Y el mismo escenario tarda en pintar los datos, algo más de un segundo

    Saludos

    sábado, 20 de octubre de 2018 7:54
  • SELECT a.intCodUnico, a.strEmpZonaRutaCuen, a.strNombre, s.strSolicitante, s.dtmFechaResp FROM tblAbonados AS a INNER JOIN tblSolicitud AS s ON a.intCodUnico = s.intCodUnico

    Estimado amigo esta es la consulta donde me muestra 65,565 filas y me tarde en mostrar

    @Hunchback

    @Javi Fernández F

    @Enrique AA

    martes, 23 de octubre de 2018 15:04
  • Saludos

    Si los campos dicen que tipo de dato son, no veo muchos registros en el ancho de la consulta (columnas), por lo cual talvez sea la red o falta de indices, ambos campos que conforman el join on tienen indice?


    Blog: www.sqlservertoolbox.blogspot.com.mx

    martes, 23 de octubre de 2018 16:37
  • Estimado ese es un ejemplo como lo estoy uniendo pero en cuanto a las columnas son mas y tablas también son como 5 
    martes, 23 de octubre de 2018 18:56
  • Hola Alexander Valle:

    Si quieres que la ayuda, te pueda ser útil, para la consulta, pégala entera.

    Índica cuales son los índices que dispone cada tabla.

    Cuanta más información aportes, más posibilidades de llegar a aportar algo que solucione tu incidencia.

    martes, 23 de octubre de 2018 19:29