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

[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 Noteví]

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 Noteví]

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,

[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 Noteví]

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.

[Casimiro Noteví]

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

[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

[Jere_84]

Bueno en el caso de MS SQL Server 2008, al utilizar el like no da error aun que el campo sea string o int el comodin '%' funciona bien. Pero si en lugar del like utilizo el '=' en los campos integer da error del tipo:

Sintaxis incorrecta cerca de '%'.

Bueno muchas gracias Roman.

Saludos.