There's also <a href="https://github.com/voormedia/rails-erd" rel="nofollow">https://github.com/voormedia/rails-erd</a> and my favorite <a href="https://github.com/amatsuda/erd" rel="nofollow">https://github.com/amatsuda/erd</a> which is fully interactive (can write migrations based on changes from the UI)
I recently discovered schemaspy and while it took a bit of working knowledge of java (need to execute a jar file from the command line) to get it working, it’s absolutely fantastic and one of the most sophisticated tools for dealing with ERDs at the DB level. Plus it’s open source! The only things I see that are possible improvements with this product are the fact that you don’t need to bootstrap a local database to generate this and it’s probably faster and easier to generate. I had a reasonably complex schema (200 ish tables with relationships) and schemaspy took about 3 minutes to generate the output. Once you do generate it though, it’s just a bunch of html and SVG in a folder so you don’t have to regenerate it until your scheme is updated.
I appreciate the side project but it's very hard to read. It doesnt really show much anything either. I much prefer <a href="https://github.com/voormedia/rails-erd" rel="nofollow">https://github.com/voormedia/rails-erd</a><p>Example: <a href="https://camo.githubusercontent.com/f705fefa37f808758adbfa8e53d7ba2d8d9a59d7/68747470733a2f2f766f6f726d656469612e6769746875622e696f2f7261696c732d6572642f696d616765732f656e746974792d72656c6174696f6e736869702d6469616772616d2e706e67" rel="nofollow">https://camo.githubusercontent.com/f705fefa37f808758adbfa8e5...</a>
In a more general sense, I don't understand why we can't define field attributes in ONE spot and have most of the application software automatically just use that info rather than reinvent it in code?<p>Things were moving that way in the 80's it appeared, then OOP came along and overzealous practitioners declared RDBMS and tables as an official evil. Sure, different screens or reports may need different subsets of such fields, but filters can be built to sort or filter different "views" as needed per usage point. (OOP is good for some things, but not others.)<p>I'm tired of retyping or mass-replicating the field wheel. Let's return to table-oriented programming and data dictionaries. It's a D.R.Y. sin. Code is NOT the best place to store most field info. (RDBMS can also store navigation, screen, and menu info, but one thing at a time. 90% of typical CRUD could be done in a declarative sense.)<p>You are welcome to disagree; I encourage spirited debate.
It doesn't work. When I import my schema.rb file it takes issue with basically every line saying things like unexpected token etc. I'm using the "upload schema.rb" file button, but it's like it's trying to parse it as SQL.
This is really nice!<p>To those trying it out: if the diagram seems inaccurate, try dragging tables around.<p>I uploaded a very simple schema, but seemingly unrelated tables looked connected. Turns out it's 100% accurate, but relationships can run behind other tables and make it look like things are connected that aren't. Detangling is easy with a few drags/drops and you get a really nice diagram out of it.
This is super useful, for Django you can use the Django-Extensions [1] to generate a similar, static representation.<p>[1] <a href="https://django-extensions.readthedocs.io/en/latest/graph_models.html" rel="nofollow">https://django-extensions.readthedocs.io/en/latest/graph_mod...</a>
This looks really great and seems to handle some things better than rails-erd (multiple relationships between the same 2 models).<p>Are there any plans to make the interactive version exportable or embeddable? I'm working on an application right now that this UX would be perfect for.
Looks neat! I was unable to use it on my more recent Rails projects which all have schema version that contain underscores. Example: `ActiveRecord::Schema.define(version: 2018_10_23_121007)`.