I've taken a look to this.

I made a quick change to add the tables to the diagram.

This is the list of implemented work so far:

• Adding tables to diagram
• Tables displays table name and fields with icons (PK and regular field)
• Moving around the tables in the diagram

Pending minimal work:

• Displaying icon for foreign keys
• Resizing tables (manually)
• Resizing tables to fit content
• Drawing references between tables
• Saving diagram in project file
• Deleting tables from the diagram

Items to be discussed:

• Adding tables using the DB Schema dock (just implemented) or through the embedded table list (initial approach).
• Raising and lowering tables? Maybe it's enough if the table is raised when clicked/moved.
• Currently if a table is added twice to the diagram, two instances appear. Do we want this?
• Has the "Database Diagram" be open by default? I think so. It has to be added to restoreOpenTabs, then.
• Should the tab be named "Database Diagram"? I'd drop "Database", as self-evident. I'd do it also for "Database Structure", by the way.

Features that would be nice to have, but not essential:

• Adding tables by dropping them from the dock to the desired position in the scene
• Printing
• Automatic placement of new tables in diagrams
• Automatic layout for adding all tables to the diagram (easier if we solve the previous point)
• Editing table and field names and references

This would implement#913 and#1260

@schdub Ping. Just in case this is still an area of interest for you. 😄

Awesome! This looks already much better than I dared to imagine 👍

Adding tables using the DB Schema dock (just implemented) or through the embedded table list (initial approach).

I fully agree with your approach here. I guess the embedded list was just there because the code is quite old and we probably didn't have the schema dock back then.

Has the "Database Diagram" be open by default? I think so. It has to be added to restoreOpenTabs, then.

Makes sense. I just forgot to add it torestoreOpenTabs when rebasing the code. No intention there 😄

Should the tab be named "Database Diagram"? I'd drop "Database", as self-evident. I'd do it also for "Database Structure", by the way.

Probably yes. As for the "Database Structure": It does make sense but I'm not sure how habit-breaking it would be for long time users. That said, we have all these issues regarding multiple instances of the Browse Data tab and I have just started working on this. It's probably going to take a long time until we have this actually working but when we add this one day it's probably a good time to rename the old tabs as we like.

From memory, the "official" name used for these kind of things is Entity Relationship Diagram (ERD). eg a diagram of theEntity Relationship Model

That being said, it's probably not the right term to choose as almost no-one would know what it means. 😉

From memory, the "official" name used for these kind of things is Entity Relationship Diagram (ERD). eg a diagram of the Entity Relationship Model

Sure :-)

If you wish to get some inspiration you can also take a look at how DBeaver (open source Java software) has implemented this same feature:
https://github.com/dbeaver/dbeaver/wiki/ER-Diagrams

The purpose of "Show tables lists"? A userwould expect to click/right click/drag a table from that list onto the diagram pane. Doesn't work. Knowing to select a table from "DB Schema" seems counter intuitive and makes the "Show tables list" redundant/waste of space.

The "table magnet" action going on is painful. Selecting a table and moving it around causes another table on the display to be "repelled" to a new location. I can see users getting ticked at this "feature".

One thing that would be "nice", harkening back to my MSAccess days, would be to generate "automagically" the diagram from the structure of an existing database.

This then begs the question...have we accounted for the one-to-one, one-to-many, many-to-one, and many-to-many type relationships that can exist between tables?

This needs work...

The purpose of "Show tables lists"? A userwould expect to click/right click/drag a table from that list onto the diagram pane. Doesn't work. Knowing to select a table from "DB Schema" seems counter intuitive and makes the "Show tables list" redundant/waste of space.

Yes, it would be redundant. "Show tables lists" was the idea of the original author, but now with the Schema dock, it makes more sense to add the tables from there. For making the action more intuitive, I'd add a message to diagram scene when it's empty:

"Add tables to this diagram by dragging and dropping them or using the contextual menu from the "DB Schema" dock"

When the first table is added, the message will be deleted.

The "table magnet" action going on is painful. Selecting a table and moving it around causes another table on the display to be "repelled" to a new location. I can see users getting ticked at this "feature".

There isn't any magnet if I understand what you mean by that correctly. The question is: the scene has an initial dimension equal to the panel, when you move a table outside of that frame, the scene grows and the center of the canvas moves. This might give the impression that the other tables are moving, but in fact it's the scene view what is moving.

One thing that would be "nice", harkening back to my MSAccess days, would be to generate "automagically" the diagram from the structure of an existing database.

Would be easy if we know how to layout the tables correctly. An initial vesion could simply add them in a grid layout independently of the relations they have: so the relation lines could form a mesh, but would be a start.

This then begs the question...have we accounted for the one-to-one, one-to-many, many-to-one, and many-to-many type relationships that can exist between tables?

That is used by MS Access for automatically generating queries, isn't it? Since we are not currently generating any query on behalf of the user, relations different to the established by the foreign key constraint are probably out of the question, at least as a first step.

This needs work...

Undoubtedly!

Can be useful:
qvge - Qt Visual Graph Editor.
nodeeditor - Qt Node Editor. Dataflow programming framework.
adaptagrams - libraries for constraint-based layout and connector routing for diagrams.
dunnart - constraint-based diagram editor.

@MKleusberg@mgrojo@scottfurry Any idea how much tweaking this would need, to get it working for putting in our nightly builds?

Am thinking that since we've branched off thev3.12.x stuff, now is probably the time to get stuff like this intomaster and having people test it via the nightlies.

@justinclift - yeah. I'm guilty here. It fell off my "projects" plate. I'm in the middle of python stuff at the moment and didn't get to this.

No worries, I have that happen all the time too. 😄

@MKleusberg I've seen various open issues requesting this feature (#913,#1260,and#2034). Any chance someone will work again on this eventually?