Si recordáis, hace unos días os comenté que había empezado a hacer un editor gráfico para sqlite. La idea era manejar en una pantalla más o menos como ésta:

Hacer que las líneas, que representan las relaciones Foreign Key entre las tablas se muevan y sigan a la tabla según las mueves. Que si haces drag and drop entre dos campos de dos tablas se establezca la relación de foreign key y que pulsando botón derecho sobre los cuadraditos verdes puedas cambiar el tipo de acción de la foreign key o eliminarla, etc.
Que con doble click sobre la tabla se abre un formulario de edición donde puedes añadir, borrar o cambiar cualquier campo, etc.

Todo muy bonito. Lo mejor que ya lo tengo hecho y funciona... más o menos. Pero hasta ahora lo he probado con pequeñas bases de prueba hechas por mí. Esta tarde se me ha ocurrido hacer la prueba con la base de datos que incorpra Calibre en sus bibliotecas y que contiene tropecientas tablas... sin ninguna Foreign Key. Funciona a la manera antigua (y compatible con todas las versiones de sqlite por antiguas que sean) a base de Triggers y demás posibilidades. Crea tablas virtuales y tablas reales con campos virtuales, usa tablas sin rowid y con rowid y en total dispone de 47 tablas, 74 índices, 59 Triggers y 17 Vistas.
¿Cómo representas eso de forma gráfica?. La pantalla se convierte en un galimatías de cuadraditos sin orden ni concierto que en lugar de ayudar lo que hacen es estorbar.
Entonces se me ha ocurrido una idea ¿Por qué no se va a poder hacer con cada uno de los tipos lo mismo que se hace con las tablas?. Una vista se puede tratar como una tabla (menos en lo que a la edición se refiere), y un Trigger se puede tratar (más o menos) como una relación Foreign key.
Hacemos algún tipo de panel o algo así y podemos dibujar rayitas en los trigger que vayan a las tablas que intervienen en su código interior.
y podemos asignar un colorín a cada tipo de línea y a cada tipo de objeto, y si hay demasiados subividir en pantallas y vistas generales y si...
y de repente ves que tienes curro para meses, años quizá.
Me estoy planteando si dejar mi programa en un mero visor gráfico de foreign keys... pero me parece algo triste y pobre hacer eso.
Ahora lo estoy contando después de todo el día tecleando y como que no estoy muy optimista.
Mañana será otro día.



Saludos

La pantalla se convierte en un galimatías de cuadraditos sin orden ni concierto que en lugar de ayudar lo que hacen es estorbar.

Se me ocurre que de alguna manera se pueda seleccionar lo que se muestra en el formulario mediante una lista de todos los objetos y un checkbox para determinar si se muestran o no... es una idea, pero esto plantea el problema de mostrar y ocultar tablas que ya tienen una relación. ¿Cómo solucionas tener oculta una tabla relacionada con otra visible?

El programa tiene un aspecto formidable y para ser honesto, no creo que ninguno de mis proyectos vayan a ser tan complejos como el que citas. Por lo tanto, para un uso "normal" lo encuentro sobradamente válido.

¡Enhorabuena!

Desde una ignorancia que se ha limitado a un par de bases de datos más bien simples en LOffice, estoy de acuerdo con don Jesús —de cuando en cuando rebautizado intempestivamente Juan por mi torpeza—. Para lo que yo hago, me sobra y me basta. Bases de datos con pocas tablas y relaciones sencillas.
Incluso me atrevo a decir que la mayor parte de las bases de datos comerciales no van más allá de un puñado de tablas. Véase como ejemplo... tu ejemplo de «expresfú». Una aplicación que funciona para el noventa por ciento de las necesidades es mejor que una aplicación que no funciona para el noventa y nueve por ciento de las necesidades. Vaaale, funciona, pero hay que complicarla bastante . —Por cierto, a ver si me aplico el principio, que soy muy jesuítico.—

Todo muy bonito. Lo mejor que ya lo tengo hecho y funciona... más o menos. Pero hasta ahora lo he probado con pequeñas bases de prueba hechas por mí. Esta tarde se me ha ocurrido hacer la prueba con la base de datos que incorpra Calibre en sus bibliotecas y que contiene tropecientas tablas... sin ninguna Foreign Key. Funciona a la manera antigua (y compatible con todas las versiones de sqlite por antiguas que sean) a base de Triggers y demás posibilidades. Crea tablas virtuales y tablas reales con campos virtuales, usa tablas sin rowid y con rowid y en total dispone de 47 tablas, 74 índices, 59 Triggers y 17 Vistas.
¿Cómo representas eso de forma gráfica?. La pantalla se convierte en un galimatías de cuadraditos sin orden ni concierto que en lugar de ayudar lo que hacen es estorbar.
Entonces se me ha ocurrido una idea ¿Por qué no se va a poder hacer con cada uno de los tipos lo mismo que se hace con las tablas?. Una vista se puede tratar como una tabla (menos en lo que a la edición se refiere), y un Trigger se puede tratar (más o menos) como una relación Foreign key.
Hacemos algún tipo de panel o algo así y podemos dibujar rayitas en los trigger que vayan a las tablas que intervienen en su código interior.
y podemos asignar un colorín a cada tipo de línea y a cada tipo de objeto, y si hay demasiados subividir en pantallas y vistas generales y si...
y de repente ves que tienes curro para meses, años quizá.
Me estoy planteando si dejar mi programa en un mero visor gráfico de foreign keys... pero me parece algo triste y pobre hacer eso.
Ahora lo estoy contando después de todo el día tecleando y como que no estoy muy optimista.
Mañana será otro día.

Shordi, antes de nada, felicitaciones nuevamente porque tiene todo un aspecto impresionante.
Cuando manejas informacion a esta escala (cientos de tablas y relaciones entre ellas) sugiero que ordenes el tema en escenarios, con botones o algo similar. Cada escenario mostrara:

• Las relaciones entre tablas, pero con controles laterales como un listview que muestren la lista de tablas que intervienen con una marca que indique si interviene en una relación o no. Esto permitiría apagar las tablas aisladas por ejemplo o mostrar solo las que interesan, o mostrar todo lo relacionado con una tabla y las secundarias a las que esta apunta.
  
• Vistas, en esta solo mostrar las vistas y las tablas que esta relaciona y nuevamente controles laterales que puedan ocultarse/mostrarse y seleccionar tablas u otras vistas.
  
• Editor de texto con resaltado de sintaxis para crear o editar vistas manualmente.
  
• Compatibilidad, permitir que el usuario pueda elegir entre versiones sqlite para crear la BBDD con la compatibilidad deseada pues tal vez no interese una compatibilidad con sqlite del inicio de los tiempos sino solo un par de años.
  

La filosofía es partir el problema en problemas mas pequeños y luego resolverlos uno a uno. Entonces cuando tengas resuelto unos cuantos tal vez la visión general cambie de imposible (años) a posible (semanas).
Y finalmente acá estamos para ayudar dentro de lo posible o sugerir cambios que tal vez se te escapen, pensamiento lateral le llaman .

Gracias Tincho. Por ahí van los tiros. Estoy probando distintas aproximaciones (Colores distintos para los distintos objetos, Tablas, Vistas, Tablas Virtuales, Triggers, etc.; Distintas pestañas para verlos por separado, Listbox o Combobox con la lista de objetos desde los que pinchas y arrastras, etc.) Aún no sé qué voy a implementar. De momento me inclino por lo de las pestañas... o no. Todo son pruebas. Eso sí, las imágenes que os he puesto muestran un drawingarea que contiene un gridview para cada tabla. Se me hizo necesario crear una clase que se comportase y respondiese a los eventos y métodos de un gridview, pero que permitiese cambiar su tamaño y color de la cabecera (aún no sé si añadir un icono o no....) y a eso he dedicado estos dos últimos días.
En cuanto haga un par de pruebas y configure un par de cosas, subiré a gitlab el primer borrador de SQetchLite (...vale, es un chiste. Ya sabéis que lo de Sketch significa borrador en inglés pero no os preocupéis. Yo tampoco me he reído.


Saludos

Ya sabéis que lo de Sketch significa borrador en inglés

Bueno, sketch seria mas bien borrador o boceto, mientras que para lo que nosotros llamamos borrador creo que la voz inglesa seria draft

---

En cuanto haga un par de pruebas y configure un par de cosas, subiré a gitlab el primer borrador de SQetchLite

Perfecto, así le echamos un vistazo.