9 respuestas en este tema

[JRichard]

Saludos.

Paso por aquí a ver que me aconsejan en cuanto al método que tengo pensado utilizar para realizar las búsquedas desde un formulario en Delphi.

Desde hace tiempo he venido leyendo artículos sobre el uso de vistas (VIEW), según lo poco que se las vistas son el resultado de consultas preparadas en el manejador de base de datos, normalmente se hacen cuando una consulta se va a utilizar muchas veces y requiere cierto grado de complejidad. Por ejemplo JOIN entre varias tablas. La vista mostrará el resultado del JOIN y se comportara como una tabla, lo que quiere decir que se puede consultar mediante el SELECT *FROM nombre_de_vista y aplicar condiciones WHERE. También tengo entendido que las vistas pueden ser modificables o no pero este depende de las instrucciones que se estén utilizando.

Bueno en mi caso no necesito que sean modificables. El asunto es que tengo varios formularios de búsqueda, PRODUCTOS, CLIENTES, PROVEEDORES, entre otros. Cada uno de estos formularios tiene una tabla donde se mostraran los registros pero estos registros serán mostrados a partir de un filtro. Adjunto dejo una imagen del formulario de búsqueda para PROVEEDORES y así tengan una mejor idea.

Ok, el formulario tiene un TEdit que servirá para introducir los datos a buscar. Cada vez que se introduzca un carácter los registros se irán filtrando según los caracteres que se vayan introduciendo y la opción que se haya seleccionado en el TComboBox.

Entonces, mi idea es crear vistas que contengan los datos que voy a mostrar en las tablas ya que cada vez que introduzca un carácter la misma consulta se estará realizando para filtrar los datos en la tabla. Y para no ir directamente contra la tabla en la base de datos pienso que es más rápido filtrar los registros de una vista que ya tiene la estructura de datos deseada.

Otra forma que vi fue la de utilizar procedimientos almacenados, pero no me parece correcta ya que ejecutar un procedimiento almacenado cada vez que se introduzca un carácter sería como sobre cargar el manejador de base de datos.

No se si estoy en lo correcto, y pues no tengo experiencia con aplicaciones grandes y no se muy bien cuando utilizar vistas o procedimientos almacenados. Con esto no quiero decir que mi aplicación vaya a tener un gran alcance pero si me gustaría saber que recomendaciones me dan ya que el asunto se complica cuando una base de datos comienza a crecer mucho y se necesitan aplicar métodos para optimizar y darse cuenta tarde que se pudo haber utilizado una vista en lugar de consultar una o varias tablas directamente generara un trabajito algo tedioso.

Espero sugerencias. 
 

Archivos adjuntos

•  4555_088cbd8b9460edad05b464a1b5ceb36ec9f66546.png   18,67KB   13 descargas

[Caminante21]

Hola

Yo utilizo procedimientos almacenados para hacer las búsquedas y no he tenido problema alguno..

Saludos

[Delphius]

Las vistas son una buena opción para estos casos. Ya que como dices, puedes aplicarles el filtro correspondiente y hasta indicarle que campos mostrar.
Ahora bien en lo posible hay que evitar lanzar reiteradamente consultas incrementales. Sobre todo si se hace sobre tablas con muchos registros y varias veces constantemente. Por tanto la lección es no abusar de las consultas incrementales.

Cuanto más filtrado sea la vista o el conjunto de datos a mostrar, mejor será tanto para el motor como para la aplicación ya que no deberá recurrir a más filtros.
Supongamos que tu deseas aplicar un filtro, y luego otro más, y otro más. Lo más sano es directamente aplicar una sola consulta que filtre por los tres.
Las consultas incrementales implica estar consultando cada vez que se cambia el texto. Y si esas tablas son muy grandes y si la vista no está muy bien pulida es un costo para el servidor tener que ejecutarla N veces en poco tiempo. Para eso lo más sano será arrojar una sola vez la consulta con todos los filtros esperados.
Por eso algunos para evitar la sobrecarga lo que hacen es detectar cuando el usuario a dejado de escribir y recién lanzar la consulta; o bien, esperar un tiempo entre consulta y consulta.

Saludos,

[JRichard]

Saludos.

Gracias por responder.

Hola Mohicano, y pues al principio pensé en utilizar procedimientos almacenados los cree y funcionaban bien pero a medida que me fui documentando entendí que estos son buenos para trabajar con grandes operaciones y, además de esto el procedimiento almacenado es compilado en el servidor al momento de hacer su llamada, entonces llamar a un procedimiento almacenado cada vez que tipee una tecla para ir filtrando los datos que aparecerán en mi tabla no creo que sea optimo. Y más aún si existen varios usuarios conectados trabajando con las mismas tablas y estas tablas contienen muchos registros.

El procedimiento almacenado consulta directamente las tablas en tiempo de ejecución además que se debe compilar a diferencia del las vistas que son casi que una copia exacta de la tabla si se quiere y, son consultas que se encuentran ya compiladas en el manejador, lo que implica una gran diferencia entre vistas y procedimientos almacenados, los procedimientos almacenados son muchos más poderos pero se compilan en el momento que se les llama, por ende me limito a utilizarlos solo para generar reportes o cuando debo obtener datos de una consulta algo compleja.
 
Claro, es completamente válido utilizarlos para hacer filtros, porque funcionan, pero conseguí con algunas cosas que me hicieron cambiar de parecer y no creo que sean la mejor opción, por lo menos para hacer filtros del tipo que quiero.

Estos resultados no se ven en días ni meses, pero puede que casi al año o más si se observen y, después de todo ese tiempo toca correr a buscar y pagarle a un Administrador de Base de Datos para que te ayude a resolver porque las consultas están lentas o porque el manejador no funciona como debería. A muchos programadores nos importa poco el manejador de base de datos pero la diferencia entre administrar una base de datos y programar una aplicación es mucha y apenas ahorita me estoy dando cuenta. Por tal motivo estoy buscando formas de hacer un poco más optima mi manera de diseñar las base de datos y evitar el mayor número de problemas posibles en un futuro. 

Y ok Delphius me quedo claro, entonces para evitar la sobrecarga lo que puedo hacer es detectar cuando el usuario a dejado de escribir y recién lanzar la consulta, yo estaba consultando con OnKeyPress, sería un consultar con el OnKeyDown y crearme un algoritmo que me ejecute la consulta después de cierta cantidad de milésimas de segundos. No se, es la primera idea que se me viene. 

[Sergio]

Mi experiencia es que funcionan igual de bien que una consulta compleja hecha "sobre la marcha", pero no me gusta usar vistas porque si luego cambias una tabla, tienes que rehacer todas las vistas afectadas, y si la estructura es compleja llega a ser un problema.

Así que en mi empresa solo usamos vistas para buscar cuando es una tabla muy "estable" y que una consulta normal no nos sirve por la razón que sea.

[Delphius]

No se si en verdad los procedimientos almacenados son compilados cada vez que son llamados. Me parece que en eso estás equivocado.
Si lo pienso suena ilógico que se compile cada vez que se lo invoque. Lo de esperarse es que se almacene la compilación hecha y se la ejecute con los parámetros que se les pasa; eso tiene más sentido.

Los procedimientos almacenados están más pensado para trabajar con operaciones más complejas y destinados a manejar algunas reglas de negocio que se necesiten y estén al alcance de las capacidades del motor.
En lo que hay que hacer diferencias es en los procedimientos seleccionables de los no seleccionables.
Los seleccionables devuelven un conjunto de datos, casi igual a una vista. Los no seleccionables son aquellos que se encargan se ejecutar operaciones y no devuelven conjuntos de datos.
Las vistas más que nada están pensadas para ofrecer un conjunto de datos con la seguridad de no tocar ni alterar las tablas. Son muy útiles para la confección de informes.

En ocasiones habrá que trabajar tanto con los procedimientos y las vistas, y en otras basta con uno de ellos. Todo depende de las necesidades y el análisis y diseño previsto.
Tanto los SP como las vistas tienen sus pros y contras, como sus limitaciones. Hay que saber como combinar las cosas.

Saludos,

[cram]

Que cierto lo que menciona Sergio. Y cuantas veces me pasó, tener que escribir y reescribir una vista por no tener bien definida una tabla.
Pero creo que los casos usos de un procedimiento y de una vista no son intercambiables.

Los procedimientos sirven para evitar tener que llevar muchos datos una y otra vez, a veces mas de una vez el mismo, desde el servidor hasta la aplicación para ser procesados, (según los manuales cuando el procedimiento es complicado y no puede o es muy difícil ser expresado como cunsulta). Es decir se mueve el resultado obtenido del procedimiento, hasta la aplicación una sola vez.
Por ejemplo, tener que recorrer una tabla para utilizar ciertos campos y calcular algo con cada una de sus filas y luego realizar otro proceso semejante que puede estar anidado en el ciclo anterior, implicaría tener utilizada las tablas por dicha aplicación y un tráfico más transacción activos. Mientras que un procedimiento puede obtener el resultado y pasarlo de una sola vez a la aplicación. Solo imagina unas 10K filas o más.
Las vistas por otra parte se utilizan para ocultar información, denormalizar tablas [usando joins] y alterar la forma en que se ven los datos, por dar ejemplos.
Otro caso, es el que recientemente me ocurrió (auxiliado por Rolphy Reyes) al tener que pasar datos de una base de datos a otra. Tuve que utilizar un procedimiento, mientras que según tengo entendido no hay forma con una vista (no al menos en Firebird).

No son para la misma tarea, aunque se puede realizar tareas semejantes y obtener resultados iguales, solo depende del caso.
2+2 = 4
2*2 = 4
2^2 = 4

Saludos.

[JRichard]

Saludos.

Gracias por responder y, pues tomare en cuenta todas las indicaciones que me han dado, realmente no existe una respuesta definitiva pero la idea es saber más o menos cuando y como utilizar cada objeto de la base de datos.

[cram]

Recientemente tuve un caso en que opté por un procedimiento antes que una vista, por lo engorroso, por no decir desastroso, que resultaría el segundo caso.
Me pidieron crear un listado de precios de artículos ordenados y agrupados con los siguientes datos:
1. Código interno
2. Denominación
3. Precio
4. Porcentaje de entrega de adelanto o como quieras llamarle
5. N1 cuotas
6. N2 cuotas
7. N3 cuotas
donde 5, 6 y 7 son tres columnas donde figura el valor de cada cuota para N1, N2 y N3 cuotas respectivamente (3, 6 y 9 cuotas por ejemplo).

El tema es que con una vista solo tengo que agregar esas cuatro columnas de valores a financiar y listo. Pero para hacerlos variables introduciendo parámetros de la aplicación para obtener listados diferentes, la cosa se complica mucho. 
Para colmo me piden que elimine los valores decimales.
Recurriendo a un procedimiento un ciclo FOR SELECT con un SUSPEND para obtener cada resultado y pasando fácilmente los cuatro parámetros. Todo cambia. 
Espero que te sirva el ejemplo. A mi me sirvió darme cuenta que con las vistas me iba a volver loco.
Saludos.

[Marc]

No se si en verdad los procedimientos almacenados son compilados cada vez que son llamados. Me parece que en eso estás equivocado.
Si lo pienso suena ilógico que se compile cada vez que se lo invoque. Lo de esperarse es que se almacene la compilación hecha y se la ejecute con los parámetros que se les pasa; eso tiene más sentido.

En efecto, Firebird almacena los procedimientos almacenados ya compilados. Al igual que hace con triggers y vistas.

Por eso puedes eliminar el código fuente de procedimientos almacenados, vistas y triggers en las bases de datos que distribuyes a tus clientes (aunque personalmente no creo que valga la pena).

http://www.firebirdfaq.org/faq316/

Los procedimientos almacenados están más pensado para trabajar con operaciones más complejas y destinados a manejar algunas reglas de negocio que se necesiten y estén al alcance de las capacidades del motor.
En lo que hay que hacer diferencias es en los procedimientos seleccionables de los no seleccionables.
Los seleccionables devuelven un conjunto de datos, casi igual a una vista. Los no seleccionables son aquellos que se encargan se ejecutar operaciones y no devuelven conjuntos de datos.
Las vistas más que nada están pensadas para ofrecer un conjunto de datos con la seguridad de no tocar ni alterar las tablas. Son muy útiles para la confección de informes.

En ocasiones habrá que trabajar tanto con los procedimientos y las vistas, y en otras basta con uno de ellos. Todo depende de las necesidades y el análisis y diseño previsto.
Tanto los SP como las vistas tienen sus pros y contras, como sus limitaciones. Hay que saber como combinar las cosas.

Saludos,

Tienes razón en que cada objeto tiene su función. Pero como los procedimientos almacenados de Delphi son tan tremendamente flexibles, personalmente ya nunca utilizo vistas, siempre recurro a procedimientos almacenados y así solo tengo que lidiar con un tipo de objeto (que además permite más potencia que las vistas, para cuando la necesitas).

Aunque hay cosas que se pueden hacer con las vistas, que no se pueden hacer con procedimientos almacenados. Y es que las vistas no tienen que ser de solo lectura, sino que pueden ser modificables e incluso tener triggers por si se quiere actualizar más de una tabla.

Personalmente nunca he utilizado estas updatable views, pero hay que reconocer que parecen una construcción con su utilidad.