Pues eso, el título lo dice todo y para no gastar teclas lo he presentado en un vídeo



El programa no funciona aún, y la prueba es que la mitad del tiempo del vídeo me lo paso intentando explicar los fallos que surgen en la pantalla... y tosiendo, eso también 
Lo he subido a mi canal de gitlab, como podéis ver en la descripción del vídeo de Youtube... y aquí, claro:

https://gitlab.com/shordi/SQetchLite

En el vídeo ya podéis ver fallos estrepitosos del código apresurado, como que todos los campos Integer los identifica como Autoincrementales y demás. Lo arreglaré. Lo que más me interesa son sugerencias y problemas de manejo que os parezcan interesantes: ¿Deberían poder ocultarse tablas? ¿debería poder hacer varios layouts para una misma base de datos? etc. etc.
Los bugs... estoy en ello, estoy en ello... pero si me los señaláis quizá haya alguno que se me pasase por alto.

Y nada más. Es un proyecto con el que me estoy divirtiendo mucho y que, espero, acabe siendo útil para alguien.

Saludos.

Acabo de actualizar el git con los bugs más gordos que aparecen en el video corregidos.
Aunque voy a repasarlo ahora a ver si he olvidado alguno.

Y nada más. Es un proyecto con el que me estoy divirtiendo mucho y que, espero, acabe siendo útil para alguien.

Hola Shordi aquí te paso algo de feedback

1) Si el programa esta pensado para diseñar las bases de datos tal vez seria mas sencillo trabajar contra un archivo SQL de texto y no contra un archivo .db es decir el binario sqlite.
2) También podrías trabajar con un archivo JSON para guardar el diseño de la base de datos en un formato neutro y luego:

• Exportar .sql para diferentes motores.
  
• Crear el .sqlite o .db binario usando los comandos de sqlite de la terminal.
  

Las vistas yo las hago así:

Código:

CREATE VIEW "view_gardens" AS SELECT
    gardens.idx AS idx,
    gardens.name AS name,
    locations.name AS location,
    stations.name AS station,
    owners.name AS owner,
    shapes.name AS shape,
    gardens.azimuth AS azimuth
    FROM gardens
LEFT JOIN locations ON gardens.location=locations.idx
LEFT JOIN stations ON gardens.station=stations.idx
LEFT JOIN owners ON gardens.owner=owners.idx
LEFT JOIN shapes ON gardens.shape=shapes.idx
ORDER BY gardens.idx,gardens.name ASC

Esto es lo que finalmente funciono y dejo de dar problemas de ambigüedad a la hora de crear las vistas cuando habia dos o mas tablas que tenian nombres de campo iguales como "nombre", "descripcion", etc.

---

Cuenta como creas (gráficamente) las tablas y las flechas.
¿Cada tabla es un formulario?

---

Ya digo que muy chulo.

Pero antes tengo que ver los otros vídeos.

1) Si el programa esta pensado para diseñar las bases de datos tal vez seria mas sencillo trabajar contra un archivo SQL de texto y no contra un archivo .db es decir el binario sqlite.

No, no, el objetivo, no sé si lo llegaré a conseguir, es hacer un editor de base de datos. Un diseñador "gráfico" de SQL no llevaría ni creador de consultas ni manejo de datos ni nada. La idea es poder trabajar con cualquier base sqlite.

2) También podrías trabajar con un archivo JSON para guardar el diseño de la base de datos en un formato neutro y luego:

• Exportar .sql para diferentes motores.
  
• Crear el .sqlite o .db binario usando los comandos de sqlite de la terminal.
  

Lo del JSON no tiene mucho sentido. Un editor de bases de datos que necesite de otros formatos para guardar datos es como ser "Clase B" . De hecho, cuando lo empecé usaba sólo, como siempre hago, la clase Settings y luego añadí la base de datos Configs.db para las demás configuraciones. Estoy pensando en eliminar la clase Settings de la ecuación: ¿para qué usarla si tengo una base de datos entera para guardar todo lo que necesite?

Sql se exportará, naturalmente, pero sólo para formatos sqlite. No aspiro a más. Si una vez terminado, allá por 2060, apareciese como conveniente ampliar... pues bueno se plantearía.

Crear un .db binario desde un sql es algo que ya hace... si se le mete la sentencia adecuada, claro.

Gracias por el feedback. Subiré un vídeo sobre cómo hacer las rayitas dichosas y demás.

Solicitud de característica.
En general diseño las bases en papel y luego escribo el SQL en gedit. 
Ahora mismo estoy diseñando una base de datos y utilizo minder, en lugar del papel, para plasmar las tablas necesarias y los campos principales.
En el método de trabajo que vengo usando hace mucho tiempo, la base de datos es creada en el primer inicio del programa a partir de dicho archivo SQL no desde un binario sqlite ya creado.
Para cubrir este espacio de trabajo (en la manera que yo lo uso) seria necesario que tu programa permita diseñar una base de datos y luego guardar el SQL, es decir seria interesante que permita editar el archivo de texto SQL y que también uno pueda crear una tabla típica a modo de plantilla para crear nuevas tablas.

...seria necesario que tu programa permita diseñar una base de datos y luego guardar el SQL, es decir seria interesante que permita editar el archivo de texto SQL y que también uno pueda crear una tabla típica a modo de plantilla para crear nuevas tablas.

Partir de un texto SQL escrito por tí es algo que ya hace: Tan sólo copia y pega en el generador de SQL y ejecuta la sentencia.

Exportar a SQL la base de datos es algo previsto. Tanto con datos como sin ellos. No problemo.

Lo de plantilla de tablas... no sé muy bien qué quieres decir. Ahora cuando creas una tabla se crea en el formulario con el campo id  tipo integer, primary key y autonumerico, es lo más parecido a una plantilla que se me ocurre.

Saludos

Excelente trabajo.

Edit:
Si es GPL voy a forkearlo para una cosa que tengo pensada. Nada que ver con BD, pero los diagramas de conexión de tablas me sirven de puntapié.

No forkees el subido, he cambiado (y mejorado, creo) todo el sistema visual. Dame un día que lo suba al github...

Saludos

para una cosa que tengo pensada. Nada que ver con BD, pero los diagramas de conexión de tablas me sirven de puntapié.

algo como esto?