Consumo de memoria de vistas locales.

Hello Grupo

Hace un buen rato trabajo en VFP y todas las aplicaciones que he
desarrollado hasta ahora han sido Cliente / Servidor con bases de datos de
Access y SQL Server. Todos los procesos contra la bases de datos los hago
por medio de ODBC, SPT y vistas remotas.

Hoy día requiero hacer una aplicación monousuario y para ello quiero usar
las bases de datos de VFP. (DBC)

Para lo anterior se deben usar vistas locales y parametrizables.

Mi gran duda es la siguiente:

Que sentido tiene usar vistas locales parametrizables si de igual forma al
abrir la vista me esta cargando dos sesiones de datos? (una con la vista y
los registros del parámetro enviado y la otra sesión de datos con la tabla
original y todos los registros)

En la medida que la tablas crezcan la apertura de la vista local será mas
lenta porque igual esta cargando las tablas que la conforman con todos sus
registros?

De antemano gracias por sus respuestas.



Oscar Arley Yepes Aristizabal.
Medellín - Colombia

Hello Grupo

Hace un buen rato trabajo en VFP y todas las aplicaciones que he
desarrollado hasta ahora han sido Cliente / Servidor con bases de datos de
Access y SQL Server. Todos los procesos contra la bases de datos los hago
por medio de ODBC, SPT y vistas remotas.

Hoy día requiero hacer una aplicación monousuario y para ello quiero usar
las bases de datos de VFP. (DBC)

Para lo anterior se deben usar vistas locales y parametrizables.

Mi gran duda es la siguiente:

Que sentido tiene usar vistas locales parametrizables si de igual forma al
abrir la vista me esta cargando dos sesiones de datos? (una con la vista y
los registros del parámetro enviado y la otra sesión de datos con la tabla
original y todos los registros)

En la medida que la tablas crezcan la apertura de la vista local será mas
lenta porque igual esta cargando las tablas que la conforman con todos sus
registros?

De antemano gracias por sus respuestas.



Oscar Arley Yepes Aristizabal.
Medellín - Colombia

>
>
>
> Imaginemos la tabla de clientes con los famosos 10 millones de registros
>
>
>
> No tiene sentido abrir toda la tabla para buscar solo un cliente, en el
caso
> de trabajar directamente sobre la tabla.
>

Foxpro nunca "Abre toda la tabla". Eso es imposible. No creo que ningun
lenguaje lo haga. Para eso existen las tecnicas de cache y paginacion por
las cuales no debemos ni preocuparnos pues estan resueltas desde hace
tiempo. Ahora bien, una consulta (sea una vista o un simple select-sql)

tenga que recorrer todos los registros con una condicion NO OPTIMIZADA,

duda que leera todos los registros de la tabla origen y eso sera muy

Si la consulta esta optimizada, pues se auxiliará de los índices para solo
recorrer el bloque de registros necesario para dar el subconjunto
resultante.

>
>
> Igualmente no tendría sentido usar la vista local puesto que la vista
> cargaría solo el registro necesario pero en otra sesión de datos tengo
toda
> la tabla con sus registros.
>
>

Tampoco. En la otra sesion tampoco tienes "toda la tabla". Simplemente
tienes un acceso abierto (conexion) a la tabla que con los comandos de
acceso y consulta se van cargando los registros desde el servidor.

>
> ¿Entonces cual técnica es la mas aconsejable para sistemas monousuarios

el
> uso de las dbc de fox.?
>
>

No es necesario que uses vistas locales en una aplicacion con dbc's.

trabajar directamente con las tablas y si deseas con buffers. Ahora bien,
la idea de la discusion aqui es que se demuestra que usar o no vistas
locales no tiene importancia porque el secreto de la rapidez de las
consultas esta en usar correctamente la optimizacion Rushmore aun en la
sentencia sql en que se basa la vista local. Con C/S es otra la

Aqui estamos hablando de DBC's

>
> O será que me estoy preocupando mucho por eso?
>
>

sin duda alguna

>

>
>
>
> Imaginemos la tabla de clientes con los famosos 10 millones de registros
>
>
>
> No tiene sentido abrir toda la tabla para buscar solo un cliente, en el
caso
> de trabajar directamente sobre la tabla.
>

Foxpro nunca "Abre toda la tabla". Eso es imposible. No creo que ningun
lenguaje lo haga. Para eso existen las tecnicas de cache y paginacion por
las cuales no debemos ni preocuparnos pues estan resueltas desde hace
tiempo. Ahora bien, una consulta (sea una vista o un simple select-sql)

tenga que recorrer todos los registros con una condicion NO OPTIMIZADA,

duda que leera todos los registros de la tabla origen y eso sera muy

Si la consulta esta optimizada, pues se auxiliará de los índices para solo
recorrer el bloque de registros necesario para dar el subconjunto
resultante.

>
>
> Igualmente no tendría sentido usar la vista local puesto que la vista
> cargaría solo el registro necesario pero en otra sesión de datos tengo
toda
> la tabla con sus registros.
>
>

Tampoco. En la otra sesion tampoco tienes "toda la tabla". Simplemente
tienes un acceso abierto (conexion) a la tabla que con los comandos de
acceso y consulta se van cargando los registros desde el servidor.

>
> ¿Entonces cual técnica es la mas aconsejable para sistemas monousuarios

el
> uso de las dbc de fox.?
>
>

No es necesario que uses vistas locales en una aplicacion con dbc's.

trabajar directamente con las tablas y si deseas con buffers. Ahora bien,
la idea de la discusion aqui es que se demuestra que usar o no vistas
locales no tiene importancia porque el secreto de la rapidez de las
consultas esta en usar correctamente la optimizacion Rushmore aun en la
sentencia sql en que se basa la vista local. Con C/S es otra la

Aqui estamos hablando de DBC's

>
> O será que me estoy preocupando mucho por eso?
>
>

sin duda alguna

>

Hola Oscar:

Efectivamente cuando utilizas vistas parametrizadas se abren las tablas

están involucradas en esa vista, pero esto es tan solo para que tu vista

pueda tomar los datos que filtrarás mediante tu vista y asi tan solo te

manda a memoria los datos filtrados, esto tiene una mejor aplicación en

ya que teniendo la base de datos en el server los datos que se envian

máquinas son únicamente los necesarios para correr tu aplicación,

con lo que

se disminuye el trafico en la red.