A problem that I run into with every single tool that does this is that any database that I would _like_ to have an ERD of, is inevitably too insane to be cleanly represented by an auto-generated ERD.
Yup, I have the same problem with UML diagrams. I always end up drawing the UML or ER diagrams by hand (i.e. manually), incorporating the tables/fields/relationships that seem interesting, leaving out the things that aren't. Then I update the diagrams multiple times as I start to understand the system better, or make changes to it.
Hi, if you are working in Ruby or Java, you might be interested in my project which is called AppLand (https://app.land). AppLand dynamically draws visualizations of web services, code paths, and SQL queries. The information is obtained primarily by running test cases; a browser plugin can also be used to step through the app and create a recording, which is then visualized in AppLand. AppLand gives you an end-to-end depiction of your code and data flows, so it's broader in scope than a static analysis (e.g. class diagram). And unlike APM (e.g. New Relic) you get detailed information about code internals (parameter values, function calls, etc).
Best of all, you can filter the views down to specific classes, keywords, and web service routes, which solves the scaling problem ("too many nodes!") that one generally finds with UML or ERD on large projects.
The approach that I am taking is to narrow the ERD to a specific context, such as a single HTTP server request route. When the specific tables and relationships are rendered for just that route, a manageable amount of data is presented.
This approach also provides metadata that can be used to figure out which tables are being used where in the code, and vice versa.
I have been thinking along these same lines as our architecture has gotten more complex over the years. I've toyed with the idea of adding some sort of comment syntax into our codebases that would allow some level of automation around this idea. Auto-generation might work quite well given the limited context, to your point.
bxparks|5 years ago
kgilpin|5 years ago
Best of all, you can filter the views down to specific classes, keywords, and web service routes, which solves the scaling problem ("too many nodes!") that one generally finds with UML or ERD on large projects.
kgilpin|5 years ago
This approach also provides metadata that can be used to figure out which tables are being used where in the code, and vice versa.
Context is king!
thisisbrians|5 years ago