Cita:
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:
Código:
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
Código:
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....!!!