rendimiento del evento data - Versión para impresión +- Comunidad Gambas-es (https://gambas-es.org) +-- Foro: Gambas (https://gambas-es.org/forum-3.html) +--- Foro: Bases de Datos (https://gambas-es.org/forum-6.html) +--- Tema: rendimiento del evento data (/thread-1711.html) |
rendimiento del evento data - alberto-moyano - 24-06-2024 Hola gente, mi consulta es la siguiente, tengo una tabla que es chica en términos de entradas (hoy ronda los 3500 registros y en un par de años con suerte si llega a los 20.000) pero es muy grande en cantidad de columnas (109), la cuestión es que la carga del gridview es muy lenta, no estoy usando el evento data, ya que tengo entendido que su mejora influye sustancialmente cuando se manejan grandes volúmenes de información, que no es mi caso, lo que tengo es una tabla con muchísimas columnas. ¿Mi creencia sobre el evento data es correcto?, o muchas columnas también debe ser tratado como gran volumen de información. La tabla es única, no tiene claves foráneas, porque no las hay, sus datos son únicos y no llevan relación con ninguna otra tabla, ¿es aconsejable partirla (en varias tablas), aún en estos casos? En el gridview solo necesito ver los datos de 7 columnas, tiene sentido usar una tabla con esas 7 columnas y otra tabla con las restantes columnas y relacionarlas con una clave foránea. Que opinión tienen ustedes. Gracias de antemano por cualquier comentario esclarecedor. Este es el código que utilizo para cargar la vista, borre todas las lineas para no cansar con la lectura Código: Public Sub Mostrar_ListaBIB() Y el código para generar una nueva entrada, no tiene problemas Código: Public Sub BtnNuevoBib_Click() RE: rendimiento del evento data - tincho - 24-06-2024 (24-06-2024, 21:21)alberto-moyano escribió: no estoy usando el evento data Pues deberias (24-06-2024, 21:21)alberto-moyano escribió: ¿Mi creencia sobre el evento data es correcto? No (24-06-2024, 21:21)alberto-moyano escribió: Que opinión tienen ustedes. Tendría que ver la tabla para dar un aopinin puntual, pero en lineas generales, si la tabla tiene columnas en las que van a repetirse datos muchas veces por ejemplo vas a tener una lista de libros y luego Borges va a aprecer 20 veces y Asimov 30 entonces tenes que usar una tabla secundaria con autores y así sucesivemente con todos los campos que sigan la misma filosofia. RE: rendimiento del evento data - alberto-moyano - 24-06-2024 Tincho, gracias por tu respuesta, voy a modificar el código para migrar al evento data. Sobre usar una tabla para autores lo veo muy complicado, ya que BibLaTeX (a través de su parseador, biber) tiene su propia lógica de conectores, por ejemplo la palabra and se convierte a «y», «e», «&» o «et al.» según corresponda al estándar de referenciación de salida elegido y esto me llevaría a tener que construir una función que refleje la suma de autores, además hay una categoría para los autores que no son públicos (others) Pablo Pozzi and Alejandro Falco --> puedo obtener: Pozzi, Pablo y Alejandro Falco; Pozzi, P. y A. Falco; Pozzi, P. & A. Falco (fijate que el parseador hace el enroque de nombre/apellido para el primer autor) Si necesito que la palabra and se refleje tal cual, va entre llaves (Pablo Pozzi {and} Alejandro Falco) otro caso es Pablo Pozzi and others --> voy a obtener: Pozzi, Pablo et al. o Pozzi, Pablo y otros (según que estándar) y la cosa se complica aún más cuando hay más de 3 autores. Voy a hacer algunas pruebas separando la tabla en 2, una que lleve los datos que deseo mostrar en el gridview y otra con los restantes a ver si con eso mejoro la velocidad, al margen de migrar al evento data. El idioma y las editoriales y su lugar de origen si me parecen aplicables a la lógica de tu comentario, voy a trabajar también en eso. Gracias nuevamente RE: rendimiento del evento data - tincho - 25-06-2024 (24-06-2024, 22:19)alberto-moyano escribió: El idioma y las editoriales y su lugar de origen si me parecen aplicables a la lógica de tu comentario, voy a trabajar también en eso.Si es verdad que un libro puede tener varios autores, no tomes el comentario al pie de la letra, solo la idea. Si la tabla tiene mas 100 campos seguramente se pueda resumir, te dejo un ejemplo del diseño que hice, y no termine, para hacer un formulario para editar bibliografía la otra vez. Otro trucos pasan por usar la palabra reservada SQL Limit [1] o usar algún filtro con Where o Like puesto que no tiene ningún sentido enviarle 5000 registros al gridview cuando este podrá mostrarte unos 25 por vez. [1] https://www.sqltutorial.org/sql-limit/ Código: CREATE TABLE "authors" ( |