Hola. Disculpame que recien contesto. Pero estuve alejado por temas laborales. Justamente me paso algo similara a lo que te sucede, Adrian. Estuve trabajando con casi 700.000 de registros. En ese momento me di cuenta que no se puede hacer Selects y que despues php haga calculos. Se hacia muy lenta las cosas.
La solucion la encontre con las siguientes cosas: 1.- Optimizar las consultas. Dijiste que haces calculos con los registros pedidos. Mi propuesta es que hagas esos calculos en la misma consulta. De esa forma, explotas mas al MySQL. Lo que quiero decir es que es MUCHO mas rapido cuando las operaciones la hace MySQL directamente. Explota las funciones matematicas de MySQL. 2.- Hace estas consultas en Procedimientos Almacenados. En mi caso, aumento mucho la performance. 3.- Si tus registros no cambian con tanta frecuencia. Utiliza la opcion de cache: SELECT SQL_CACHE y configura al cache al tamaño que necesites 4.- Algo que me resulto fantastico, fue la utilizacion de ADOdB para PHP. El mismo tiene cache y todo. Esta barbaro. Con esos pasos, optimice mucho mi tiempo. Suerte. --- Adrian Pablo Ali <[EMAIL PROTECTED]> escribió: > Joyisima :-) , buena idea Gustavo, la verdad que no > cambian tan seguido > los datos y hacer un programa para que mande de > mysql a un txt lo datos > seria algo facil y rapido para el mysql y el > servidor. Ahora que no se > si serviria para mi caso, porque yo no solo tengo > que presentar los > datos en pantalla como estan en la base, tengo que > hacer calculos sobre > ellos y en base a eso presentar la info en pantalla, > entonces estaria > leyendo una y otra ves ese archivo que seria > grandecito y creo que ahi > seria mas lento que con la base de datos. Lo mismo > me sirve la idea para > unos listados grandes que tengo que hacer en donde > los datos no cambian, > gracias. > > Gustavo Cortez wrote: > > >Hola Adrián, mientras leia tus post y los de > Mauricio, se me ocurrió que > >preguntar con cuanta frecuencia cambian esos 300mil > registros, porque > >una solución podría ser volcar el contenido en un > archivo, y luego > >compararlo con el estado actual de la consulta (que > se puede hacer > >guardando dos archivos, uno con la id solamente y > otro con todos los > >datos separados por ','). El archivo con las id, > que supongo que son > >única e irrepetible, se pueden ir comparando con > las id de la base de > >datos si alguno no coincide, se hace un volcado de > todos los datos > >nuevamente al archivo en cuestión. Eso sería a > nivel del servidor de > >base de datos. Para no tener que pasar tanta > información del mysql al > >apache, apache (o php) solo tendría que leer de un > archivo de texto, y > >si se hacen varias consultas simultaneamente, mejor > aún porque solo se > >leería de un texto. > >El tema de seguridad e implementación no los tuve > en cuenta porque nunca > >hice algo parecido, pero leí en un libro de php > donde hacía consultas > >enormes y hacía la transferencia al servidor web > demorando muchisimo > >tiempo... en base a esto, el autor proponía una > solución similar a la > >que expuse arriba. También vi que hacían algo > parecido en la lista de > >posgres. Si no conseguis solución sería bueno darte > una vuelta por esos > >lares y plantear tu problema a ver que te dicen. > > > >Saludos, > >Gustavo > > > > > > > >------------------------------------------------------------------------ > > > >_________________________________ > >Lista de correo - L U G Tucumán > >http://www.lugtucuman.org.ar > > > > > > > _________________________________ > Lista de correo - L U G Tucumán > http://www.lugtucuman.org.ar > __________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas _________________________________ Lista de correo - L U G Tucumán http://www.lugtucuman.org.ar
