This might be silly, but having tools like that built into MySQL Workbench, alongside both forward and backward engineering (get SQL from model and apply it, or get a model from an existing DB) is one of the reasons why I very much enjoyed working with it: https://dev.mysql.com/doc/workbench/en/wb-eer-diagrams-secti... (I might otherwise often prefer PostgreSQL, especially due to the procedural language and transactional DDL), also works fine with MariaDB for the most part
In most projects I've seen people just do some generic models (not even proper ED diagrams) and write some SQL migrations to be applied with something like dbmate or Flyway and call it a day, though working on DB schemas feels like one of the areas where model driven development actually makes a lot of sense and feels natural, if the tooling is there! Otherwise you end up with the actual schema and the models you make diverging slightly over time, either due to people forgetting to add stuff, or you yourself missing something. That's also why I enjoy the likes of DbVisualizer for getting a nice overview about what's actually in the schema: https://www.dbvis.com/
Language in that gif reminds me of DOT, from apt install graphviz which is pretty widely used I think. Various tools I use (including some I wrote or worked on) output to DOT format because it's so simple, and from there you tell the tool to make it into the appropriate format for your pdf report or webpage or so: `cat diagram.dot | dot -T png > diagram.png`. The DOT format is not as simple as dbdiagram though! But it's also not limited to database diagrams: https://en.wikipedia.org/wiki/DOT_(graph_description_languag...
In case someone wished this exists but for something other, or more versatile, than database diagrams, although dbdiagram as a product looks way more polished and integrated
$ man dot | grep --context=10 svg
OUTPUT FORMATS
Graphviz uses an extensible plugin mechanism [...] Traditionally, Graphviz supports the following:
-Tdot (Dot format containing layout information),
-Txdot (Dot format containing complete layout information),
-Tps (PostScript),
-Tpdf (PDF),
-Tsvg -Tsvgz (Structured Vector Graphics),
-Tfig (XFIG graphics),
-Tpng (png bitmap graphics),
-Tgif (gif bitmap graphics),
-Tjpg -Tjpeg (jpeg bitmap graphics),
-Tjson (xdot information encoded in JSON),
-Timap (imagemap files for httpd servers for each node or edge that has a non‐null href attribute.),
-Tcmapx (client‐side imagemap for use in html and xhtml).
I use it in my project to document the schema. We keep the markdown file in source control so that we update it whenever we make database changes. We also have an extension that allows viewing it as the diagram in vscode in our .vscode\extensions.json file.
There are some disadvantages however:
1. The foreign key relationships aren't completely clear
2. The diagram became difficult to navigate in vscode as our schema grew in size
I think most people would mean something like using the foreign key constraints information schema views to understand the relationships, print out the columns, etc - its really a pretty trivial SQL query to create mermaid relations (though your engine of choice may not have all the metadata you want) but its actually difficult to find the right level of granularity - its very easy to make a lot of visual noise in mermaid.
Doesn't seem to work on mobile at all. Tables that I add are not shown in the diagram. The diagram area is not visible unless I scroll sideways.I cannot scroll sideways, unless I request desktop site and scroll there. But I still don't see any entities in the diagram. When I use the buttons to add tables in the diagram, they also do not show up in the grid, but only on the left in the textual list of tables. Seems like a complete non-functional tool on mobile.
Usually I wouldn't care too much about a tool like this running on mobile, but not at a PC right now, so that's all I can give feedback about.
I had the opposite problem, was given SQL ddl with near 1000 tables and hundreds of constraints, and had to produce the schema map. Ran the ddl and connected it to yEd, and hey presto, schema map!
The truth is that if you are modeling a relationship set of 1000 tables you probably cant usefully show that to someone - you can produce an image but nobody can likely use it.
Instead, consider breaking things down to functional areas and then modeling those - just like how most city thinking is "well get on this main road and then this secondary road will get me to XYZ"
Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not sure how you'd get useful DDL out of it -- none of the columns have types, no indices, etc.!
Maybe an LLM could sketch out a DDL skeleton from a picture, which someone could use as a starting point?
Tooling is a big reason I would reach for SQL Server over alternatives in many scenarios. Combining SSMS with 1-2 RedGate utilities and an Excel license is essentially the one ring of database management.
When you have a complex data model and need to constantly engage the business regarding it, having an easy way to transform, compare and visualize representations of the schema can mean the difference between ~3 clicks and a multi-day journey into the rabbit hole of shiny technology.
I would still reach for SQLite in any scenario where I am embedding the DB in software that I am distributing. But, if I need to stand up a database that multiple systems and users are all going to talk to, I am always going to advocate for spending a little bit of money.
Maybe it is me but I never find those relationships diagrams that useful.
When structure is obvious then it is obvious and I don’t need a diagram - when structure is convoluted diagram is such a mess anyway that it is not helping at all.
Is there a way to switch to numerical multiplicities/cardinalities? I always find the circle and feet notation not very readable and also less precise in some cases.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.
insane the number of ways people handle diagrams - honestly i just get lost in all the tool options. you think having too many choices slows progress or actually helps in the long run?
Honestly, i love dbeaver but the fact it doesn't respect GTK nicely and the UI hasn't gotten much love makes me want to switch to something else. I know most people don't really get bothered by it, so I'd say it's not that big of a deal. It is for me though
Other dedicated text to database diagram tools are
1. Database Diagram Tool https://databasediagram.com/app
2. QuickDBD https://app.quickdatabasediagrams.com/#/
3. ERD Lab https://app.erdlab.io/designer/guest (Requires Login to Export)
[1]: https://xosh.org/text-to-diagram/
In most projects I've seen people just do some generic models (not even proper ED diagrams) and write some SQL migrations to be applied with something like dbmate or Flyway and call it a day, though working on DB schemas feels like one of the areas where model driven development actually makes a lot of sense and feels natural, if the tooling is there! Otherwise you end up with the actual schema and the models you make diverging slightly over time, either due to people forgetting to add stuff, or you yourself missing something. That's also why I enjoy the likes of DbVisualizer for getting a nice overview about what's actually in the schema: https://www.dbvis.com/
In case someone wished this exists but for something other, or more versatile, than database diagrams, although dbdiagram as a product looks way more polished and integrated
https://docs.mermaidchart.com/blog/posts/7-er-diagram-exampl...
There are some disadvantages however:
1. The foreign key relationships aren't completely clear
2. The diagram became difficult to navigate in vscode as our schema grew in size
Usually I wouldn't care too much about a tool like this running on mobile, but not at a PC right now, so that's all I can give feedback about.
Mine is a desktop Java app. that exports XML that then gets converted to SQL (create.sql)
and ORM Java sources with the matching SQL queries. No reflection, just code generation.
Should work with MySQL (MariaDB), Postgres and Oracle.
Its feature-rich, albeit focused on Postgres. And it's ability to compare database schemas makes updating and applying diffs much easier.
He then generated SQL from the diagram and deployed the schema to PostgreSQL. The schema was shared and reviewed.
The tool is https://dbdiagram.io
You can import/export SQL and generate images of your schema.
It can also save the picture as a mermaid text for future edits. Pretty neat.
Instead, consider breaking things down to functional areas and then modeling those - just like how most city thinking is "well get on this main road and then this secondary road will get me to XYZ"
And by SQL do you mean DDL?
A hand-drawn picture of a database schema. Something like this:
https://www.dreamstime.com/stock-images-database-schema-imag...
> And by SQL do you mean DDL?
DDL is a subset of SQL, so the distinction is moot.
Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not sure how you'd get useful DDL out of it -- none of the columns have types, no indices, etc.!
Maybe an LLM could sketch out a DDL skeleton from a picture, which someone could use as a starting point?
When you have a complex data model and need to constantly engage the business regarding it, having an easy way to transform, compare and visualize representations of the schema can mean the difference between ~3 clicks and a multi-day journey into the rabbit hole of shiny technology.
I would still reach for SQLite in any scenario where I am embedding the DB in software that I am distributing. But, if I need to stand up a database that multiple systems and users are all going to talk to, I am always going to advocate for spending a little bit of money.
When structure is obvious then it is obvious and I don’t need a diagram - when structure is convoluted diagram is such a mess anyway that it is not helping at all.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.