Será buena idea que el usuario pueda hacer querys personalizadas?
 

Tengo un sistema bastante completo en producción, son cerca de 60 tablas con varios miles de registros. Sucede que con frecuencia a mi cliente se le ocurre que necesita información extraída de dichas tablas, algo asi como datamining, y me pide hacerle el "reporte" para que lo pueda consultar, sin embargo muchos de estos reportes solo los usan una única vez o bien de manera ocasional. La mayoría de estos se pueden sacar armando un query, que es lo que realmente hago. Estaba pensando en hacer un módulo que permita al usuario escribir su query y ver los resultados en un grid, aprovechando que uso Quantumgrid de DevExpress, lo que me permite que los usuarios tengan filtros, ordenaciones y exportación instantánea. La idea es que cuando necesiten algo "especial" yo solo les haga el query, se los pase y con eso lo puedan consultar con la posibilida de que la misma base de datos almacene los querys para que estén disponibles para cualquiera.

Es obvio que esto se puede hacer con herramientas externas o hasta con el vil Excel, pero la idea es que lo puedan hacer dentro del mismo sistema que ya conocen. Obviamente filtrando que el query solo pueda usar selects y no insert, delete ni update.

¿Es buena idea o no tiene caso?,

El nivel del usuario más avanzado que usa este sistema no es de programador pues ni siquiera conoce SQL.

Hola,

Como funcionalidad "avanzada" yo no lo veo nada mal y creo que puede ser útil tanto para el usuario como, por lo que dices, para ti también.

Si de todas formas vas tú a hacer la consulta SQL, también podrías proporcionar una vista y que tu aplicación "importe" las vistas.

// Saludos

Hola: Yo hace un tiempo comencé a agregar un formulario al que accedo por contraseña que contiene un memo, un boton de ejecutar, un dbgrid y un boton para exportar a excel los datos ya que siempre necesitaban algun tipo de informe que no habia sido diseñado y/o solicitado en la fase de analisis y desarrollo. De esta manera soluciono no tener que seguir agregandole cosas que, como estas diciendo, tal vez la usen una sola vez.-

Saludos

Me inclino por la solución de Roman, que pueda ejecutar vistas, las que tú decidas.

En alguna ocasión he realizado una solución parecida. Añado una tabla con una pequeña descripción y la sql que quiero que se ejecute. Con un botén de ejecutar cargo la sentencia en los componentes del formulario y se ejecutan. También suele ser necesario incluir los tipos o máscaras de los campos. Para añadir nuevas posibilidades al usuario, sólo hay que incluir registros en esa tabla. Obviamente, esta tabla no puede manejarla el usuario. Si te pide algo nuevo, le pasas el procediminto para insertar un nuevo registro en esa tabla y que pueda ejecutarlo. Si luego él puede ordenar, sacar totales, filtrar, etc, ya tienes la solución.

Saludos

Yo siempre añado una opción para ejecutar SQLs.
Incluso con un mantenimiento de esos sqls, se pueden guardar, ponerle una descripción de lo que hace, volver a ejecutarlos, borrarlos, modificarlos, etc.
Cada una almacena la fecha de creación, de ejecución, etc. en fin, un mantenimiento muy completo.
Se informa que esas sentencias a ejecutar pueden ser peligrosas si no saben lo que están haciendo y, además, se mantiene un registro de los sqls ejecutados por si acaso luego vienen con un "se han perdido las ventas de todo un año y yo no he tocado nada".
Miro la tabla de sqls ejecutados y veo una que dice: "delete from tbventas where year=2010"
Por supuesto, cuando se ha ejecutado la sentencia aparecen al terminar los botones "confirmar" y "cancelar", que hacen 'commit' y 'rollback', que es ahí donde al usuario le debería de caer las gotas de sudor por la frente pensando si le da a uno o a otro botón :D
Básicamente se usan para procesos repetitivos que ha pedido algún cliente y no merece la pena añadir un módulo para ello porque nadie más lo usaría.
Y también para cosas "nuestras", arreglos de meteduras de pata por parte del usuario, etc.

bueno, pero los usuarios, los capacitarías en el uso de SQL? que tipo de usuarios son? porque si aun teniendo donde generar el query te van a llamar para que les generes un reporte, pues no serviría de mucho, como parte del sistema se me hace una opción muy buena, por ejemplo en mi trabajo, hay varios sistemas donde puedes generar querys, pero hay usuarios que no quieren generarlos y hablan para que les generen la información...

Claro, normalmente es el cliente que llama con una petición del tipo: "Me haría falta un listado de los clientes que no tengan email, ordenados por nombre y agrupados por provincia".
Le paso el sql, se guarda, se le pone un título: "Clientes sin email, ordenados alfabéticamente y agrupados por provincia". Así pueden ejecutarlo cuando lo necesiten otra vez.
Además el resultado se puede imprimir, exportar a pdf, txt, csv, xls, html, etc.

p.d. Por cierto, normalmente me conecto por control remoto y yo hago todo el proceso.

p.d.2: Así era en la empresa en la que ya no trabajo, y en la anterior, y en la anterior a la anterior... :)

Lo que quiero lograr es lo que dice Casimiro. Yo haria los querys se los paso ya ellos los ejecutan. Voy a implementarlo y les cuento como quedó igual y le sirva a alguien.

Pues a lo mejor yo soy el unico que piensa en el $$, pero para mi es una oportunidad de negocio el que le desarrollemos todos los reportes que necesite. :cool:

^\||/

(¿se nota que tengo poco tiempo para escribir mis respuestas?) :D

Idem..

Saludos

Amigo, pero es que el tiempo que estoy atendiendo a ese cliente... se le cobra. Y la creación del SQL también.

Normalmente es algo así como:
Tenemos un "control de seguimiento" donde anotamos todo lo que hacemos y luego es la administración de la empresa la que se encarga de pasar la factura al cliente.

Juanelo, al contrario, así se gana más dinero, si creas un informe ya no le sacas más rendimiento porque es igual para todos :D

Ya decía yo, ahora me siento mejor ... :D
Claro siendo Chuck Norris ... :D:D:D

Hola.

En la empresa el producto tiene un generador de reportes creado por la misma compañia.

El usuario puede crear el diseño tal cual lo quiere. Luego puede asignar a las bandas del diseño las consultas y hasta subconsultas anidadas con parametros y todo. Para que muy bueno.

Pero por mucho que se le explique el manejo a los usuarios no dan para diseñar, modificar o buscar errores del generador de reportes. Y ahi viene entonces la llamada de soporte, la visita, capacitación si se requiere y por lo tanto el cobro.

Ten encuenta que el hecho de que tu aplicación tenga un diseñador de reportes le dará un beneficio/servicio mas que otros productos similares (lo tengan o carezcan de el). Esto hará que tu aplicación se pueda vender como mas personalizable. Ello no conllevará a perder los ingresos por soporte o diseño de reportes sino que generará otro tipo de servicio/soporte del cual podrás usar como herramienta de trabajo la propia herramienta y además algunos reportes bastante complejos no podrán ser generados por la herramienta.

je, je, je... :cool:

Sí, lo que comentas es así, es una oportunidad añadida para captar más trabajos/servicios/... dinero :)