MySql y Delphi Lento

[nasedo]

Estoy migrando una aplicacion hecha en Delphi 4 y Paradox que utiliza como componente de enlace a la base de datos el BDE, la migracion se esta haciendo a Delphi 6 y MySQL, el problema radica en que las consultas u otras cosas que tengan que ver con tablas, querys en Paradox corre bien a buena velocidad de acceso (un poco lento pero se puede trabajar), pero no asi en Delphi 6 y MySQL, ya que las consultas a la misma tabla tardas mucho en MySQL (no se puede trabajar asi con tanta lentitud) al final parece que resulta peor... bueno mi pregunta es... alguien sabe por que esta pasando esa lentitud en las consultas en MySQL? estoy utlizando un componente de paga que se llama MySQLDAC.... sera dicho componente?? he probado el Zeos Access y de igual forma me resulta lento, algun consejo? gracias!!

[[AzidRain]]

No es logico lo que dices, pero ayudaria que pusieras algun ejemplo de query que estes corriendo en uno y otro y por otra parte que comentaras en que consiste esa migración.

MySQL dispone de herramientas de importación mucho muy rápidas que se pueden aprovechar para estos casos.

[roman]

Algo a tener en cuenta, es que mientras con paradox uno está acostumbrado a trabajar con tablas como un todo (componente Table), en MySQL (y cualquier servidor SQL) esto no es recomendable porque es muy costoso en tiempo y recursos, traer todos los registros desde el servidor. Por eso, la filosofía cambia y es mejor trabajar con consultas SQL con condiciones adecuadas para restringir los registros que se envian al cliente.

Dicho llanamente; si estamos buscando un cliente de apellido CORCUERA, en paradox quizá haríamos:

tblClientes.Filtered := true;
tblClientes.Filter := 'apellido = "CORCUERA"';
tblClientes.Open;

Esto hace que la aplicación cliente lea todos los registros de clientes en memoria y luego los filtre. En una tabla de escritorio como paradox, eso no es tan malo porque los datos están muy próximos. Pero con un servidor SQL, con los datos muy posiblemente en otro ordenador y con acceso via TCP, la situación cambia totalmente. Es mejor, entonces, hacer una consulta

select * from clientes
where apellido like "CORCUERA"

ya que la selección se restringe en el servidor mismo, y sólo se mandan al cliente los registros que satisfagan las condiciones.

Otro aspecto a tener en cuenta para las velocidades, son los índices. Índices adecuados pueden ser la diferencia entre horas y segundos para una consulta.

// Saludos

[nasedo]

Empezado por AzidRain

No es logico lo que dices, pero ayudaria que pusieras algun ejemplo de query que estes corriendo en uno y otro y por otra parte que comentaras en que consiste esa migración.

MySQL dispone de herramientas de importación mucho muy rápidas que se pueden aprovechar para estos casos.

Lo que pasa es que en la aplicacion que utiliza paradox abren la tabla completa (aproximadamente 120000 registros para la tabla clientes) y de ahi hace table.Setrange y Locates... y eso resulta algo "rapido ya cargada dicha tabla" si lo intento en MySQL es terrible el tiempo, lo intento con Consultas mysql pero aun asi resulta lento el proceso... mi primer duda fueron los componentes antes mencionados ... Gracias!!!

Saludos....!!!

[nasedo]

Empezado por roman

Algo a tener en cuenta, es que mientras con paradox uno está acostumbrado a trabajar con tablas como un todo (componente Table), en MySQL (y cualquier servidor SQL) esto no es recomendable porque es muy costoso en tiempo y recursos, traer todos los registros desde el servidor. Por eso, la filosofía cambia y es mejor trabajar con consultas SQL con condiciones adecuadas para restringir los registros que se envian al cliente.

Dicho llanamente; si estamos buscando un cliente de apellido CORCUERA, en paradox quizá haríamos:

tblClientes.Filtered := true;
tblClientes.Filter := 'apellido = "CORCUERA"';
tblClientes.Open;

Esto hace que la aplicación cliente lea todos los registros de clientes en memoria y luego los filtre. En una tabla de escritorio como paradox, eso no es tan malo porque los datos están muy próximos. Pero con un servidor SQL, con los datos muy posiblemente en otro ordenador y con acceso via TCP, la situación cambia totalmente. Es mejor, entonces, hacer una consulta

select * from clientes
where apellido like "CORCUERA"

ya que la selección se restringe en el servidor mismo, y sólo se mandan al cliente los registros que satisfagan las condiciones.

Otro aspecto a tener en cuenta para las velocidades, son los índices. Índices adecuados pueden ser la diferencia entre horas y segundos para una consulta.

// Saludos

Estoy totalmente de acuerdo contigo, pero aqui entra un detalle, como comenté tan solo la tabla Cuentas es de aproximadamente 120000 registros, resulta que los usuarios no se saben todas las cuentas y tienen que consultarlas en un grid donde se despliegan dichas cuentas, para asi, ayudarlos a encontrar y seleccionar la adecuada y aqui es donde entra mi martirio con la carga en el grid de TODAS las cuentas... alguna opinion al respecto??? GRACIAS!!

Saludos....!!!

[roman]

Ahí está el punto. Desafortunadamente las personas que están acostumbradas a trabajar con sistemas tipo paradox o access, piensan que necesitan tener a la vista todos esos datos, les da una falsa sensación de seguridad. Pero basta meditarlo un poco para percatarse de que nadie necesita tener esa cantidad de registros a la mano, nadie realmente va a revisar 120,000 registros para buscar uno en particular. Por lo general, simplemente desplazarán rápidamente el grid- que estará convenienemente ordenado -hasta llegar a la zona donde piensan que puede estar el dato que buscan. Una vez en esa zona, revisarán- ahí sí con detalle -unos cuantos registros (cien o doscientos a lo sumo). Ahora, ¿cómo identifican esa zona de probabilidad? Necesariamente es porque conocen algún dato, o parte de algún dato, y el orden de los registros les ayuda a llegar a la zona. Pero eso mismo es entonces lo que requieres para hacer una consulta SQL adecuada. El ejemplo del apellido está sobre simplificado, pero ilustra el concepto. En lugar de desplazarse por entre 120,000 registros hasta la zona de las C's (porque recuerdan que el apellido que buscan es CORCUERA), lo que harán será escribir "CORCUERA" en un cuadro de edición, oprimir un botón y esperar a que el servidor les regrese los clientes de apellido CORCUERA.

En resumen, para encontrar un registro entre 120,000, el cliente debe saber algo acerca del registro, es imposible que revise todos y cada uno de ellos. Ese algo es el parámetro que pasas a tu consulta SQL.

Algo que puedes hacer, es darle ambas opciones: el despliegue total y la búsqueda según criterios. Pronto se convencerá que la búsqueda es mucho más efectiva, sobre todo si la haces versátil. De un recorrido lineal de 120,000 registros, les das ahora un cuadro de búsqueda donde pueden pedir "todos los clientes cuyo apellido paterno empiece con COR, su nombre contenga MARIO y que vivan en una calle cuyo nombre contiene SURG, es decir, algo que ni siquiera esperaban que podían hacer.

// Saludos

[nasedo]

Antes que todo una disculpa por ser algo descortes y no darles las gracias... gracias por contestar a TODOS.

Tienes mucha razon, la gente esta mal acostumbrada, y eso que planteas esta en el sistema anterios, el cliente presiona el boton y se le presenta otra ventana la cual despliega las cuentas y busquedas filtradas, como lo comentaste, ahora lo que voy a "tratar" es acostumbrar a los usuarios a solo hacer las busquedas filtradas, sin datos en el grid, y dependiendo lo que quieran buscar les irá apareciendo en el grid, estoy en lo cierto no? muchas graciass por todo colega...

{Saludos}