DrawERD makes it easy to visualize your database structure
drawerd.com
drawerd.com
I cant click to enlarge the few screenshots (so I cant take a better look)
I cant try the tool without subscribing and creating an account
And I agree with you, replace this generic gif of a a person sitting on a desktop with a screenshot of the tool or something more relevant
Owner: I say this not to be harsh but as an honest piece of advice: if you want to catch my interest, show me a demo.
I'm not trying to be negative, but the site is not doing the business any favors.
The $5/mo Pro plan says "Up to 50 team members"
Just to clarify, that means $5 per person who can share within their 50 person team, right?
The free plan seems quite reasonable/generous 100 diagrams/5 members. It says "Purchase Now" though instead of "Sign Up"
Downsides are I need to have the Java JVM installed to use it. Also had to do some make a custom property file to make it work with postgres 12 the last time I used it.
For MySQL users on macOS, Sequel Pro can export your schema to graphviz format as well - [1]
[0] - https://www.jetbrains.com/help/idea/creating-diagrams.html [1] - https://www.norbauer.com/rails-consulting/notes/erd-diagrams...
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!
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.
Not only it says "Get Started" instead of "Online demo" and "Sign up Free"/"Login" instead of "Download" (or even "Free Trial"), but it is illustrated with an unprofessionally colorful generic guy in front of a laptop instead of anything remotely representative of what the application is and does.
The word “many” is clutter in an ERM, every arrow by default is a one to many arrow. It's presence probably suggests that your arrows are backwards from what I would do, they should point in the direction of data access which you can do, they are always many to one. The word “one” is nice, but because in practice it is created by a unique index on a column on the referring table, I have always denoted it with a small black line perpendicular to the arrow on that root side. Also missing seems to be nullable foreign keys, which should be denoted with an open circle at the root of the arrow, for the same reason. The fact that you have to put so much stuff on this side is the only reason I don't like Crow's Foot notation.
And, like, one of course wants bi-directional arrows representing a many-to-many relationship but one would like to zoom in on that and see the actual table maybe.
Growing this thing outward, you want to teach people how to think with it. Two diagrams two paths on a diagram which start from the same place and follow arrows until they get to the same place, suggests a consistency danger. Probably you intend one row in the source table to only map to one row in the destination table, what happens if the two paths give me a different answer? Is there a way to rephrase this so that this is no longer a problem? Furthermore, there always is because arrows come in different strengths. I can always downgrade a one-to-one into a many-to-one arrow. I can always downgrade that into a nullable many-to-one arrow. I can always downgrade that into a many-to-many double arrow. and this is enough to open that sort of double pointing relationship, deciding one of these relations to be many to many instead of many to one.
I would love to teach a virtual class on this, but the one thing I struggle with is standardizing some idea of type so that the BS is kind of cleared away. Like a lot of tables could be written as “string ComponentAssemblyCategory,” okay, it has a creation date and version tracking and whatever else, but fundamentally there is just a unique varchar in there which is the point of the table to hold. This is also necessary for those many-to-many tables to be auto-collapsible, you would find after all of the other fields are removed it would just be a `null ClientProjects` table allowing every project to have many clients or each client to have many projects.
One suggestion, you should remove the footer on your landing page if all the links just point to `#`...
Now I'm worried about where my .csv files have ended up.