Foro - Perl en Español

Buenas,

Soy nuevo con Perl, pero me han comentado que ofrece los mejores resultados en cuanto a tiempo de respuesta en búsquedas en bases de datos de cierto tamaño. Y por tamaño me refiero a entre 20.000 y 500.000 registros.

Tengo claro que no voy a tener los resultados en 1 milisegundo, pero me gustaría saber si es posible tenerlo relativamente rápido. Es para un programa web y no quisiera tener a mis clientes esperando media hora delante del ordenador.

¿Sabe alguien si hay un estudio sobre tiempo de respuesta que compare Java, Perl y Python?

Bienvenido a los foros de Perl en Español, mitxino77.

La respuesta no depende del lenguaje, sino del motor de la base de datos.

Luego, una vez obtenida la información desde la base de datos, ya depende de un lenguaje u otro el formar la salida para el usuario. Ahí se puede ganar o perder tiempo dependiendo de cómo hagamos el filtrado y el tratamiento. Aquí es donde Perl tiene muchas bazas para ganar.

Con las máquinas actuales, el elemento más lento de toda la cadena de comunicación es Internet, por lo que con una humilde base de datos en MySQL o Postgres te vale.

Gracias por la ayuda.
Tengo ambos sistemas montados y también SQLserver. De todos modos, ¿hay alguna manera de saber qué lenguaje es más apropiado para hacer consultas en bases de datos grandes vía web?

Yo creo que el lenguaje te es lo mismo, en el momento de la consulta, porque el costo de crear la consulta SQL va a ser casi exactamente lo mismo en casi cualquier lenguaje. Quizás tendrás que escribir más líneas en Java, de forma más estricta en Python y como te dé la gana (dentro de un orden) en Perl, pero casi será la mismo.

Lo interesante es luego, a la hora de procesar los resultados. Perl permite un tratamiento muy compacto de la información y su volcado en varios formatos (Excel, csv, html, texto, pdf, png, svg, etc. etc. etc.) de forma sencilla gracias a los módulos ya escritos. Incluso es posible usar Ajax con CGI::Ajax para tener un experiencia más suave con el usuario. Por regla general, en Perl se consiguen los resultados con menos líneas porque la mayor parte del trabajo ya está hecho.

Es muy posible que sí existan comentarios de qué lenguaje es más apropiado según el problema, pero creo que lo mejor es hacer una 'demo' de una consulta en esos tres lenguajes y cronometarlos. Cuidado que en ese momento dependerá de tu experiencia para saber escribir de forma óptima esa consulta.

No te olvides de cronometar también el tiempo de desarrollo en cada lenguaje. Perl tiene la fama de obtener el menor de ese tiempo de desarrollo, pero como siempre, depende de la experiencia que tengas en cada lenguaje.

Gracias de nuevo.

Coincido contigo en lo de que la parte más lenta es la de la base de datos, pero mi tarea es reducir el tiempo de respuesta desde el clic hasta que se carguen los resultados, así que me toca optimizar esa parte, la consulta SQL ya se verá que hacemos con ella.

Intentaré desarrollarlo en Java porque es así como está el resto del portal. Y luego si no he tardado demasiado procuraré enchufarle un módulo Perl para ver si cambia mucho el tiempo de respuesta.

Tengo que decir que la búsqueda es de un string, por ejemplo buscar "zapatería", y que se hace en al menos dos campos, p.e. nombre y empresa. No se si eso cambia algo.

Muchas gracias por la ayuda y la rapidez.

Hay otra opción: no uses ninguna base de datos.

Si entras en http://www.guiacolor.info/ encontrarás casi 150.000 registros de empresas y profesionales cuyos datos no están en una base de datos, sino que las páginas mostradas han sido pregeneradas a partir de esa base de datos.

Cuando el usuario pulsa en un determinado enlace de una empresa, sale la página con los datos de forma inmediata. Es lo más rápido que puedes conseguir.

El problema sigue estando en el sistema de búsqueda a partir de una caja de diálogo para buscar a partir de ese string. Sólo tienes que crear la sentencia SQL correspondiente para que lo busque en esos dos campos. Aquí la rapidez puede depender un poco de si alguno de esos campos está indexado, porque puede mejorar bastante los resultados.

Gracias, es básicamente lo que tengo que hacer, incluyéndole una u otra función de autocompletar y autocorregir, y en mi propia base de datos.

¿No tendrás el código de la función por algún casual, no?

Gracias otra vez; con esta página ya tengo un modelo por el que orientarme más o menos.