Desde que las bases de datos residen en el servidor de internet, los manejos de grandes cantidades de datos se enlentecen hasta el infinito.
Estoy haciendo una rutina que ojeando una tabla padre (de unos 3000 registros) selecciona de otra hija (que puede contener hasta 50000 (o más)) el último registro que correspondan a cada uno de los de la tabla padre, hace unos cálculos y graba unos datos y añade registros en la tabla hija.

Algo así como extraer el último apunte contable de cada cliente y añadir un apunte nuevo según el saldo que tenga.
Haciendo el proceso con Results, se hace eterno el asunto.
Para minimizar los accesos a la base he pensado pasar los registros que me interesen a de la tabla hija a un Array y meter los movimientos de las tablas en ficheros de texto .csv que luego se introducen de una en la base de datos.
Ahí me surge la pregunta:
     ¿Utilizo arrays dinámicos unidimensionales (uno por cada campo) o uno multidimensional?

Utilizar multidimensionales parece más elegante, pero este proceso se realizaría sólo de vez en cuando (trimestral) y he leído por ahí que los multidimensionales al no poder ser redimensionados, ocupan la memoria desde que abres la aplicación.

¿Alguna pista?

Y ya de paso, por si me lo ahorro: ¿alguien tiene una funcion echa que pase una tabla a un array?

===================
No podemos regresar

Para eso lo suyo es replicar mysql y así trabajas con una base de datos local y te quitas de lios.

Esta tarde pongo un pequeño manual de hacer eso que es muy simple.

[Editado]
Me ha salido algo y esta tarde no voy a poder. Vete mirando el enlace este
Replicación de MySql
Al replicar tu base de datos lo que ocurrirá es que cada cambio que se produzca en el servidor maestro (el actual) se pasará a tu mysql local de forma automática. Tu trabajas localmente y no molestas para nada al servidor maestro que tiene sus propios medios para hacer esas actualizaciones cuando sus balances de carga sean aceptables. Osea que normalmente una actualizacion será instantanea en ambos servidores, pero si por alguna razón el maestro está muy cargado puede tardar algún segundo.

Solo hay que instalar otro mysql en una máquina local, hacer una copia de seguridad del maestro, volcarla en el nuevo y luego cambiar unos pocos parámetros en el maestro y el esclavo. A partir de ahí todo cambio en el maestro se hace automáticamente en el otro.
[/Editado]
 

Sorry Soplo, no me es viable. El programa se ejecuta en docenas de aparatos manejados por ususaurios que no tienen, ni quieren, bases de datos ni nada por el estilo. He hecho un primer boceto con arrays dinámicos: Uno por cada campo de la consulta, que son tres, siendo el primero el indice principal. De más de 40 minutos el proceso me tarda ahora 20 segundos... es lo que quería y creo que lo voy a dejar así. La única incidencia en el aparato del cliente es un fichero .csv que se genera en /tmp y que se carga con una sentencia SQL "load infile local" y se destruye después.

Aún así sigo sin saber si sería mejor utilizar un array mulitdimensional.

Gracias por el esfuerzo de todas formas.

===================
No podemos regresar

Citar:

Desde que las bases de datos residen en el servidor de internet, los manejos de grandes cantidades de datos se enlentecen hasta el infinito.

¿Dónde residían antes? Por cuestión de seguridad, me parece poco recomendable colocar las bases de datos en un servidor de Internet.

Citar:

Estoy haciendo una rutina que ojeando una tabla padre (de unos 3000 registros) selecciona de otra hija (que puede contener hasta 50000 (o más)) el último registro que correspondan a cada uno de los de la tabla padre, hace unos cálculos y graba unos datos y añade registros en la tabla hija.

Me parece probable que se trate de un problema de sobrecarga de la red (no del servidor).

Citar:

He hecho un primer boceto con arrays dinámicos: Uno por cada campo de la consulta, que son tres, siendo el primero el indice principal. De más de 40 minutos el proceso me tarda ahora 20 segundos... es lo que quería y creo que lo voy a dejar así. La única incidencia en el aparato del cliente es un fichero .csv que se genera en /tmp y que se carga con una sentencia SQL "load infile local" y se destruye después.

Shordi, me alegro que hayas solucionado el problema porque aparenta ser del tipo de inconvenientes que acarrean muchas quejas. Pero ahora que ya lo solucionaste me parece que deberías explorar un poco la alternativa de trasladar toda la carga de procesamiento de datos al servidor mediante procedimientos almacenados, de modo que minimizar la cantidad de información que se transmite a través de la red.

Saludos cordiales.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Pues es lo que debería hacer, Fabián, lo he pensado miles de veces, pero el problema es que yo, como soplo, desarrollo "en caliente", que soy el chico para todo. No hay tiempo para investigaciones ni perfeccionamientos. Aqui aplicamos el principio tan sólido de "si funciona no lo toques" y el españolísimo sistema de "Chapucea e improvisa, que algo queda".

Es asombroso lo que una chapuza hecha en dos días con código caótico e improvisado, puede llegar a durar y lo que te la pueden llegar a agradecer. También lo es el que cuando un módulo o rutina es especial, te ha costado sudores, lo has depurado, perfeccionado, puesto elegante y de libro... te dicen "Ah... vale, pero eso va a cambiar el mes que viene, según dicen. Yo que tú no me habría molestado"... jejeje

En concreto esto de las facturas y apuntes masivos llevo tres años esperando que me den los parámetros de ejecución y me los dieron la semana pasada... para que esté operativo antes del 1 de Marzo, que empieza el trimestre... cabrones despiadados, oiga.

Un saludo a todos, que he estado unas semanas sumergido en los html-css-javascript, etc. etc de las nuevas versiones de moodle (me ha tocado actualizar nuestra plataforma de e-learning y dar un curso sobre el tema) y no he tocado el gambas para nada. Ahora vuelvo al redil.

===================
No podemos regresar

Hombre, yo es que trabajo en un entorno de producción. La rutina es que te digan que un sistema estuvo caído durante dos horas anoche y que en ese tiempo no se facturaron bien las llamadas. Como facturamos aproximadamente 100 millones de sms diarios, veinticinco millones de llamadas y sobre diez milones de grps solo en sms puede haber un par de millones de sms sin facturar o mal facturados. Añade a eso llamadas y tal. Para que la gracia cueste cinco o diez millones de euros como nada. Así que te tienes que ir a la tabla donde están todas las llamadas recibidas no facturadas y extraer las que ocurrieron en esas horas y a partir de esas decenas de millones de registros encontrar la forma de hacer un update que les ponga a todos como es debido. A veces es un update y a veces es un script y no hay posibilidad alguna de trabajar de otra manera.

Cuando ves que determinados errores se repiten pues entonces si se hace un script como es debido, se documenta, ser versiona y se pone a disposición de todos como es debido para posibles mejoras.

Osea que siempre hay que trabajar con un método, utilizando procedimientos estándares de aproximación y resolución al problema. No soluciona nada tapar una chapuza con otra. A los informáticos todo el mundo nos pide cosas a todas horas, pero la solución a ese problema que tienes es decirle a la gente que se jodan y esperen a que esté arreglado y te tomas tu tiempo para hacer los procedimeintos y poner los medios para que esto esté bien resuelto.

Hazte valer. Si no te haces valer no vales nada y ellos no dejarán de pedir. Hace años que aprendí eso.
 

[Editado]
De todas formas yo mañana publico el pequeño tuto de replicar una base de datos mysql que es muy fácil y muy práctico. No hace daño que eso esté aquí y quizá ayude a alguien.
[/Editado]

Es cierto, muchas veces uno se ve forzado a trabajar de un modo inadecuado y hacer un "arreglo creativo" en esas situaciones, muchas veces es el único tipo de solución que se permite.

Pero como dice soplo, chapuza sobre chapuza... eso no puede terminar bien. Hay demasiadas empresas y organizaciones donde el trabajo de uno o varios informáticos es "apagar los incendios". Según CMMI la existencia de héroes (héroes porque son los bomberos de la empresa) de los que depende la resolución de problemas críticos es uno de los factores que demuestra el nivel de inmadurez de la organización.

A mí me parece que ese tipo de situaciones colaboran a la visión que generalmente tienen los compañeros de trabajo no informáticos, para quienes somos "el chico de las computadoras", algo que colabora a la desvalorización de la profesión.

Pero, al fin y al cabo, uno no siempre puede elegir dónde "currar". Además, el contexto de crisis actual hace que sea inadecuado plantearse cambiar de trabajo.

Saludos cordiales.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Al final no me ha sido posible hoy hacer el dichoso tuto, pero ya lo haré uno de estos días je je je.

Efectivamente Fabian en nuestro caso hay cosas que se hacen en plan heroe porque no hay posibilidad de hacerlo de otra forma. Cuando se pierden llamadas se pierde mucho dinero y es razonable que la empresa ponga medios (que pone muchos) para que esos fallos no ocurran y que cuando ocurran tengan personas para resolverlo por las bravas porque es mejor que nada pero el deseo de la empresa es que eso no sea necesario.

En nuestro caso valga como ejemplo todos los días se envía un "parte de guerra" a otro departamento que lo que hace es reunir información sobre nosotros y los otros sistemas y presentar un informe semanal a un consejero delegado que se dedica exclusivamente a eso. Me temo que mas de una vez se ha hablado del tema en el consejo de administración porque no hay manera siquiera de cuantificar cuanto dinero se pierde con esas caídas ni de valorar las soluciones a lo heroe que se producen. Aún así se gasta mucho dinero en evitarlo y salvo esa circunstancia ningún otro departamento (salvo los de datawarehouse que son unos mantas y trabajan a nivel de desarrollo) tienen soluciones a lo heroe ni se admiten ni siquiera se pueden hacer así como así porque la estructura lo impide. Hay que cumplir pasos y tal para poder realizar ejecuciones en las máquinas de producción.

Hacer una chapuza para solucionar la chapuza de ayer solo lleva a que mañana tengas que hacer otra chapuza para resolver la chapuza de hoy. Lo mejor para pasar de ser un bombero a un informático es enviarle al jefe un informe detallado con una auditoría del sistema informático. Donde están las cosas buenas, que se hace bien, que se hace mal, como debería corregirse y cuanto podría costar en tiempo y en dinero. Eso los jefes lo agradecen mucho porque ellos no tienen ni idea.

Yo lo hice así en su día y me fué bien en una metalúrgica en la que trabajé.
   

Tooda la razón del mundo tenéis. En mi caso no suelo chapucear demasiado. Corrigo bugs en plan bombero, eso sí, pero cuando hay que aportar una solución la aporto en serio. Mi problema es que estoy solo solito como informático en mi empresa, desde montar el hardware, echar los cables y decir dónde van los enchufes, hasta el diseño de las webs, pasando por las bases de datos, redes locales, instalación y mantenimiento de servidores, aplicaciones en gambas, plataformas de formación, etc. etc. me cae todito a mí, y no tengo tiempo que dedicar en serio a ninguna de dichas actividades.
Llevo dos años pidiendo a gritos ayuda, pero la idiosincrasia de mi empresa, de momento, no me lo permite.
Al final caes en la chapuza inevitablemente, que una chapuza tapa un incendio en diez minutos, pero un arreglo en serio hay que ponerlo en cola de espera y cola de esa tengo para varios años...

En fín, para qué contaros mis penas, sin novedad en el frente, compañeros.

===================
No podemos regresar

Cuando yo me encontré en esa situación entregué un informe a mi jefe explicando detalladamente las cosas para que se hiciera cargo de la situación. Expliqué el estado de la red en general, de donde podían venir los problemas, lo que podían costar las soluciones y luego expliqué como se estaba entregando lo que los distitnos departamentos me pedían, en que condiciones y tal.

Al hacerlo me la jugué. Si leía lo que le decían se haría cargo de la situación y quizá me daría mas medios o quizá al menos comprendería el porque de las chapuzas. Si no lo entendía me buscaría un sustituto.

Lo entendió y ese año hubo mas dinero para informática y luego hubo resultados. Dejé de hacer chapuzas y noté el respeto de la gente. Pasé de ser "el chapuzas" a ser el tio que estaba levantando todo el sistema informático. Cuando antes me reñían por tardar un día en hacer algo ahora podía decir "la solución está en desarrollo" y la gente sonreía y me decía "ya lo harás". Me iba a casa a mi hora y cuando dije que me iba a otro sitio quisieron subirme el sueldo. Ahora comprendo que al jefe todo el mundo le viene a llorar para pedirle mas dinero y que él no sabe realmente quien lo necesita. Hay cosas que ve con mas claridad que otra y la informática es la que menos ve.

También ahora entiendo que si no me hubiera escuchado me buscaría un sustituto, pero es que si no lo entendió yo debiera buscarme otro trabajo.

Así son las cosas.

 

Esa es mi experiencia.