Seguramente este generador será útil para crear consultas especiales dentro del programa una vez que este funcionando.
Puestos a pedir características te paso algunas que a mi me parecen útiles.
Puestos a pedir características te paso algunas que a mi me parecen útiles.
- Generar, de forma automática, las vistas de tablas que tengan campos foráneos
- Selector de campos a mostrar en las consultas.
- Generador de campos de sumatoria.
- Permitir crear sentencias tipo JOIN [1]
1 Saludo.
El problema no es qué puede hacer ese formulario, que lo puede hacer todo, el problema es quién va a manejar eso. Como solo es un ejemplo, no he añadido niveles de usuarios, ni de accesos... ni siquiera usuarios. Cuando usas sql así, a lo bestia,... ojo con quien lo utiliza.
En otras palabras: esta capacidad de generar consultas vía sql está (o debería estar) reservada a los administradores del sistema, a gente que sabe lo que hace. En esos casos todo lo que pides o restringe (porque nunca sabes qué consultas vas a necesitar y si limitas qué campos deben ser relacionados quizá te pases o quizá no llegues), o es innecesario porque tal como está diseñado es muy sencillo, basta con doble click en los nombres de tabla y/o campos (aunque, eso sí, puede resultar cómodo en algunas ocasiones). Aquí tienes libertad absoluta con el sql incluyendo las funciones integradas de sqlite... pero tienes que saber lo que estás haciendo, claro. Con un formulario similar a éste, en mis tiempos, llegué a generar y almacenar como vistas consultas que utilizaban el join de más de 8 tablas entre sí, sin límites.
Por otra parte, la experiencia me dice que crear nuevas consultas no es algo que se haga muy a menudo. Cuando se pone en marcha la aplicación creas, por ejemplo, las ventas del mes, los resúmenes de ingresos y gastos, el inventario de productos, etc. Estas consultas serán ejecutadas cada mes o cuando las necesites pero después de tener tu set de consultas habituales será relativamente infrecuente hacer consultas nuevas, con lo que una herramienta más "elástica" es lo mejor.
Por supuesto que dejar eso al alcance de un camarero estresado o aburrido, puede ser un desastre. No olvidemos que esto no es más que un ejemplo. Creo que haré un vídeo extra hablando de la seguridad desde el punto de vista de la aplicación de gambas.
Gracias por el feed-back.
Saludos.
En otras palabras: esta capacidad de generar consultas vía sql está (o debería estar) reservada a los administradores del sistema, a gente que sabe lo que hace. En esos casos todo lo que pides o restringe (porque nunca sabes qué consultas vas a necesitar y si limitas qué campos deben ser relacionados quizá te pases o quizá no llegues), o es innecesario porque tal como está diseñado es muy sencillo, basta con doble click en los nombres de tabla y/o campos (aunque, eso sí, puede resultar cómodo en algunas ocasiones). Aquí tienes libertad absoluta con el sql incluyendo las funciones integradas de sqlite... pero tienes que saber lo que estás haciendo, claro. Con un formulario similar a éste, en mis tiempos, llegué a generar y almacenar como vistas consultas que utilizaban el join de más de 8 tablas entre sí, sin límites.
Por otra parte, la experiencia me dice que crear nuevas consultas no es algo que se haga muy a menudo. Cuando se pone en marcha la aplicación creas, por ejemplo, las ventas del mes, los resúmenes de ingresos y gastos, el inventario de productos, etc. Estas consultas serán ejecutadas cada mes o cuando las necesites pero después de tener tu set de consultas habituales será relativamente infrecuente hacer consultas nuevas, con lo que una herramienta más "elástica" es lo mejor.
Por supuesto que dejar eso al alcance de un camarero estresado o aburrido, puede ser un desastre. No olvidemos que esto no es más que un ejemplo. Creo que haré un vídeo extra hablando de la seguridad desde el punto de vista de la aplicación de gambas.
Gracias por el feed-back.
Saludos.
Última modificación: 06-07-2024, 09:33 por Shordi.
No podemos regresar