¿Que tipo de búsqueda me conviene en ABM?

[Jere_84]

Hola club!, estoy comenzando mi tesis para recibirme y el trabajo final es hacer un sistema. Para los ABM estoy utilizando un form con una grilla, la cual tiene los botones Nuevo, Eliminar, Editar, que llevar a un segundo formulario (creo que esta es la manera típica que implementan la mayoría de los programadores) Necesito en la ventana de la grilla implementar un método de búsqueda. Imagino que debería ser un text box donde el usuario ingrese un dato y si existe el cursor se posicione en la grilla, marcando el registro. El problema es que hay varias formas de buscar los datos, necesitaría que me recomendaran cual seria la mas adecuada para este caso.
Utilizo los componentes ADODataSet.

Seria bueno quizás poder ver como lo hace algún sistema echo en Delphi, ya que este dato de búsqueda no debería ser fijo. El usuario debería poder elegir porque dato quiere buscar. Ademas, tendría que poder buscar los próximos resultados coincidentes y los anteriores.

Escucho consejos. Muchas gracias.

[Casimiro Notevi]

En nuestro 'FTP' tienes programas completos que te pueden servir de ayuda.

[[Delphius]]

¿A que te refieres cuando dices Tipo de búsqueda?
De lo que dices, todo se resume a un consulta SQL como

Código SQL [-]
SELECT tus-campos FROM tus-tablas WHERE tu-condicion-de-busqueda

Luego el conjunto de datos devuelto queda en el DataSet y será mostrado en un DBGrid si los enlazas con el respectivo DataSource. Tan simple como eso, o es que yo no entiendo el rollo.

Ahora si tu de dicho consulta pretendes localizar o refinar más las cosas, tienes a disposición el método Locate() o también de la posibilidad de filtrar gracias a Filter y Filtered. Pero ya sea cualquiera de estas dos alternativas, se pueden reemplazar y hacerlo vía sql añadiendo las debidas condiciones necesarias para ello:

Código SQL [-]
SELECT tus-campos FROM tus-tablas WHERE tu-condicion-de-busqueda AND tu-condicion-refinada

Cuanto más filtrado se regresen los datos mejor.

En el único escenario que imagino "tipos" de búsqueda es que se te ocurra traerte todos los datos (repito, lanzando un SQL), y abandonar el uso de Filtros y/o Locates() e irte por la implementación de tus propios algoritmos de búsqueda. De lo que según yo recuerdo por las clases de Estructura de Datos, solo hay dos posibilidades: Búsqueda secuencial y/o Búsqueda Binaria. El 1ro recorre el conjunto de datos evaluando elemento a elemento, el segundo sólo aplica cuando se tiene la seguridad de que los datos están ordenados (lo que nos llevaría a que la consulta SQL tenga una cláusula ORDER BY) y lo que hace es buscar en base a un elemento pivote (generalmente el elemento central) y decidir repetir la búsqueda de forma recursiva en la primera o segunda mitad del conjunto.

Saludos,

[Neftali [Germán.Estévez]]

Creo que el camino va por donde indica Delphius. Deberás generar una sentencia SQL y de forma dinámica variar el filtro (la parte del WHERE) según el campo por el que esté buscando y el valor.

A ver si esta entrada te puede servir. en este caso no se usa SQL, sino la propiedad Filter, pero puedes echarle un vistazo porque también te puede ser útil. Además trabaja con ADO.

Empezado por Jere_84

Ademas, tendría que poder buscar los próximos resultados coincidentes y los anteriores.

Esto no acabo de entenderlo y tal vez deberías explicarlo mejor, porque no lo veo trivial.

[roman]

Empezado por Jere_84

Para los ABM estoy utilizando un form con una grilla, la cual tiene los botones Nuevo, Eliminar, Editar, que llevar a un segundo formulario (creo que esta es la manera típica que implementan la mayoría de los programadores) Necesito en la ventana de la grilla implementar un método de búsqueda. Imagino que debería ser un text box donde el usuario ingrese un dato y si existe el cursor se posicione en la grilla, marcando el registro.

[...]

Ademas, tendría que poder buscar los próximos resultados coincidentes y los anteriores.

Me parece que estás tomando un camino equivocado. Es decir; por las frases resaltadas da la impresión de que tienes una rejilla en donde muestras todos los registros y tu búsqueda simplemente te colocaría en el registro encontrado.

Esto era lo que se acostumbraba antes, cuando se usaban bases de datos tipo Access o Paradox. Pero realmente no tiene mucho caso presentar al usuario cientos o miles de registros, de los cuáles sólo examinará unos cuantos.

Es más adecuado -en mi opinión- presentar una ventana de búsqueda y mostrar sólo los registros encontrados. De esta forma te evitas, además, implementar la lógica de ir "siguiendo" los diferentes resultados.

En una aplicación, por ejemplo, tengo esta ventana:



Aquí, el usuario escribe en un campo o varios de la parte superior y oprime el botón "Buscar". La búsqueda construye una consulta SQL usando AND y LIKE para los campos:

Código SQL [-]
where nombre like :nombre and apellidos like :apellidos

Los resultados coincientes -y sólamente éstos- se presentan en la rejilla de abajo.

// Saludos

[Casimiro Notevi]

En este hilo se habló sobre pantallas de búsqueda y puedes ver más pantallas, así hacerte una idea.

[roman]

Como que sentí feo que pongo mi pantalla y lo mandas a buscar otras ¿eh?

Je, je, es broma

// Saludos

[Maniches]

Quisiera sacar unas Dudas con respecto a los comentarios de Delphius y Neftali, creo que se puede hacer consulta dinámicas usando los componentes ADO. La duda me viene que cada ves que se ejecute la consulta dinámica este va al servidor y recién se compila ahí, no nos permite la opción de poder configurar INDICES, etc para que las consultas sean mas optimas.
Capaz he mal interpretado lo comentado. Seria bueno aclararlo.

Saludos.

Maniche

[Casimiro Notevi]

Empezado por roman

Como que sentí feo que pongo mi pantalla y lo mandas a buscar otras ¿eh?
Je, je, es broma
// Saludos

Algunas veces, viendo pantallas de lo que uno quiere hacer, se entiende mejor

[Casimiro Notevi]

Empezado por Maniche

Quisiera sacar unas Dudas con respecto a los comentarios de Delphius y Neftali, creo que se puede hacer consulta dinámicas usando los componentes ADO. La duda me viene que cada ves que se ejecute la consulta dinámica este va al servidor y recién se compila ahí, no nos permite la opción de poder configurar INDICES, etc para que las consultas sean mas optimas.
Capaz he mal interpretado lo comentado. Seria bueno aclararlo.
Saludos.
Maniche

Se supone que los campos para búsquedas están indexados.

[Maniches]

Yo tengo 2 Dudas:
1. Que al ejecutar un select como texto esto le da trabajo al motor de BD que este tenga que compilar la Consulta. EJM: EXEC ('select....')
2. No estoy muy seguro si las consultas dinámicas vayan a coger los indices definidos. esto quiere decir que para cualquier consulta hay que crear indices?

Capaz me este equivocando.

Me viene otra duda con respecto si una consulta dinámica que se defina en un componente ADO. en una aplicación que ejecuta muchas consultas. el ejecutarlas desde una interface o método no traería problemas de concurrencia.

Ahí dejos esas dudas... seria bueno aclararlas...

Saludos

Mancihe

[[Delphius]]

No estoy seguro de si ADO cuenta con el método Prepare(). Lo que hace este método es justamente optimizar el armado de las consultas dinámicas sobre todo si se va lanzar la misma varias veces.

Por otro lado, en lo posible hay que evitar hacer las consultas dinámicas, las que uno coloca en los componentes. Para algo los motores ofrecen las vistas. En todo caso es más saludable hacer consultas del tipo

Código SQL [-]
SELECT tus-campos FROM VISTA ....

Si una consulta nunca se va a modificar, o si resulta ser que tiene partes comunes a otras, lo mejor es justamente desapegarlo del lado de la aplicación y llevarla al motor y hacer una vista. Luego la aplicación hace uso de las vistas y no tiene que preocuparse nada más.

Esto no es una regla, sino una sugerencia. Habrá casos, inevitables, en los que se necesita armar una consulta al vuelo.

Sobre índices... Se supone que uno diseña los índices considerando el diseño de sus tablas y en base a las consultas que se realizan sobre éstas, la frecuencia con que se ejecutan, e incluso se pone en el análisis el tamaño (tasa de crecimiento) de la tabla. No es que por cada consulta se crean sus índices, sino que se definen en la base de datos un conjunto de índices que luego el motor determinará cuáles de dicho conjunto son los más adecuados para procesar las operaciones "ABM" que le solicitan. No hay que llegar tampoco a crear tantos índices como campos tenga cada tabla. Sino más bien sobre los principales campos de interés.
Elegir los índices no es cosa de un día.

Saludos,

[Maniches]

Empezado por Delphius

No estoy seguro de si ADO cuenta con el método Prepare(). Lo que hace este método es justamente optimizar el armado de las consultas dinámicas sobre todo si se va lanzar la misma varias veces.

Por otro lado, en lo posible hay que evitar hacer las consultas dinámicas, las que uno coloca en los componentes. Para algo los motores ofrecen las vistas. En todo caso es más saludable hacer consultas del tipo

Código SQL [-]
SELECT tus-campos FROM VISTA ....

Si una consulta nunca se va a modificar, o si resulta ser que tiene partes comunes a otras, lo mejor es justamente desapegarlo del lado de la aplicación y llevarla al motor y hacer una vista. Luego la aplicación hace uso de las vistas y no tiene que preocuparse nada más.

Esto no es una regla, sino una sugerencia. Habrá casos, inevitables, en los que se necesita armar una consulta al vuelo.

Sobre índices... Se supone que uno diseña los índices considerando el diseño de sus tablas y en base a las consultas que se realizan sobre éstas, la frecuencia con que se ejecutan, e incluso se pone en el análisis el tamaño (tasa de crecimiento) de la tabla. No es que por cada consulta se crean sus índices, sino que se definen en la base de datos un conjunto de índices que luego el motor determinará cuáles de dicho conjunto son los más adecuados para procesar las operaciones "ABM" que le solicitan. No hay que llegar tampoco a crear tantos índices como campos tenga cada tabla. Sino más bien sobre los principales campos de interés.
Elegir los índices no es cosa de un día.

Saludos,

Es justo lo que mencionaba en mis comentarios, es muy importante lo que has mencionado Delphius con respecto a las vistas ya que pueden llegar a cubrir la mayoría de consultas dinámicas que necesitemos y ademas estas van a estar en el motor de base datos y no van a necesitar ser compiladas al momentos de ejecutar una consulta.

El tema de los indices me refería a los que se definen en la base datos. ya que al ejecutar una consulta dinámica el motor primero tienen que compilar el query y luego después ver que indices va utilizar. Y En una vista todo esto ya estaría definido y compilado.

Creo que estas respuestas van a ayudar mucho a los amigos. tenerlo en cuenta.

Saludos,

[Neftali [Germán.Estévez]]

Empezado por Maniche

creo que se puede hacer consulta dinámicas usando los componentes ADO.

En mi caso cuando hablo de consultas dinámicas, me refiero a consultas SQL que "montas" en el momento y que no están almacenadas. Por lo tanto, eso se puede hacer con cualquier componente.

Empezado por Maniche

La duda me viene que cada ves que se ejecute la consulta dinámica este va al servidor y recién se compila ahí, no nos permite la opción de poder configurar INDICES, etc para que las consultas sean mas optimas.

En el caso de los SGBD's, el propio SGBD es el que se encarga de utilizar los índices necesarios si los tienes para optimizar las consultas. En las Bases de datos antiguas y de escritorio, era el usuario quien seleccionaba los índices a utilizar. Actualmente los sistemas "serios" generan el plan de ejecución de las consultas para minimizar tiempos, y para eso utilizarán índices si los tienen definidos.

[Jere_84]

Bueno gracias a todos por las respuestas la verdad que se me aclaro mucho el panorama. Me voy a inclinar por hacer una sentencia SQL dinamica en un ADODataSet y ir variando el where, aun que es interesante el locate voy a hacer algunas pruebas. Con respecto a los indices, en el caso de utilizar sentencias dinámicas. Me conviene hacer indices principales en aquellos campos únicos de la tabla? Esto es para favorecer la velocidad de la búsqueda imagino. Yo utilizo SQL Server 2008 Express y hasta el momento no hice indices ni principales, ni secundarios en mis tablas, pero las consultas tipo SELECT funcionan muy bien, no se que ocurrirá cuando las tablas crezcan, quizás en este punto se nota la utilización de los indices.

Otra cosa, ya que en mis ABM estoy mostrando una grilla con todos los registros de la tabla, creo que me seria conveniente utilizar un TOP 10 o 20 mostrando los últimos registros, no eh probado pero creo que es posible.

Bueno muchas gracias o todos siempre leo sus comentarios en otros post y se aprende mucho con ustedes..
Espero en algún momento devolver un poco todo lo aprendido a los que vengan en el futuro.

Saludos.

[Casimiro Notevi]

Empezado por Jere_84

Otra cosa, ya que en mis ABM estoy mostrando una grilla con todos los registros de la tabla, creo que me seria conveniente utilizar un TOP 10 o 20 mostrando los últimos registros, no eh probado pero creo que es posible.

Es que eso es precisamente lo que NO tienes que hacer.
Para eso sirve crear la consulta dinámicamente, para que el usuario seleccione lo que busca y sólo traerte el registro o los pocos registros coincidentes con los filtros seleccionados por el usuario.

[Jere_84]

Empezado por roman

Aquí, el usuario escribe en un campo o varios de la parte superior y oprime el botón "Buscar". La búsqueda construye una consulta SQL usando AND y LIKE para los campos:

Código SQL [-]
where nombre like :nombre and apellidos like :apellidos

Los resultados coincientes -y sólamente éstos- se presentan en la rejilla de abajo.

// Saludos

Hola Roman!, Me gusto esta idea. Como estas haciendo la sentencia? ¿Concatenas por código los valores de los edit en la propiedad CommandText de los data set? y en el caso de que quiera buscar solo por uno de los campos, como trabajas con eso?. Te pregunto esto porque quiero hacer lo mismo.

Saludos!!!

[roman]

Hola,

Lo que tengo es una consulta de este tipo:

Código SQL [-]
select * from tabla
where
  campo1 like :campo1 and
  campo2 like :campo2 and
  campo3 like :campo3
  ...

Al momento de ejecutar la consulta, sustituyo los parámetros de esta manera:

Código Delphi [-]
if Edit1.Text = '' 
  then Query.ParamByName('campo1').AsString = '%'
  else Query.ParamByName('campo1').AsString := Edit1.Text;

if Edit2.Text = '' 
  then Query.ParamByName('campo2').AsString = '%'
  else Query.ParamByName('campo2').AsString := Edit2.Text;

if Edit3.Text = '' 
  then Query.ParamByName('campo3').AsString = '%'
  else Query.ParamByName('campo3').AsString := Edit3.Text;

...

El usuario, si quiere, puede introducir el comodín % en sus edits para coincidencias parciales, pero si deja en blanco un edit, yo le pongo el comodín para que así ese campo realmente no forme parte de la condición (la comparación campo like '%' siempre será true).

De esta manera, el usurio puede buscar por uno o más campos, sin tener que especificar con un botón de radio o una lista de selección múltiple u otros artilugios, los campos que deben incuirse en la búsqueda; además de que, como tal, la consulta SQL es fija, si necesidad de construirla al vuelo.

// Saludos

[Jere_84]

Empezado por roman

Hola,

El usuario, si quiere, puede introducir el comodín % en sus edits para coincidencias parciales, pero si deja en blanco un edit, yo le pongo el comodín para que así ese campo realmente no forme parte de la condición (la comparación campo like '%' siempre será true).

De esta manera, el usurio puede buscar por uno o más campos, sin tener que especificar con un botón de radio o una lista de selección múltiple u otros artilugios, los campos que deben incuirse en la búsqueda; además de que, como tal, la consulta SQL es fija, si necesidad de construirla al vuelo.

// Saludos

Claro, yo pensaba un combobox para que el usuario seleccionara el campo, la verdad que no se me habría ocurrido el tema de los comodines, y en el caso de que el campo sea tipo integer? el comodín '%' también es valido? Que tipo de comodin usas cuando es por ejemplo un Código y es tipo integer? No tengo para hacer pruebas en este momento.

Bueno saludos Roman y muchas gracias.

[roman]

Bueno, el modelo de consulta que te puse es para el caso específico de la pantalla que te mostré. Si hay campos numéricos, quizá dependa un poco de la base de datos que uses. En el caso de MySQL, un campo, aun siendo númerico, puede asignarse su valor como si fuera string. O se que no habría diferencia en el código expuesto.

Pero creo que hay bases de datos en que asignar un valor string un campo numérico puedes ser causa de error, aunque el string represente un número. Tendrías que probar.

// Saludos