The Apache-licensed DBeaver is too limited for my needs: it exists to advertise their "DBeaver PRO" commercial license and features, but even then you cannot get a perpetual license for DBeaver PRO: it's subscription-only; their Enterprise edition claims to not require Internet access - but is not intended as a single-user software product (and it's priced accordingly).
In short: DBeaver simply won't sell me what I actually want.
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?
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.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.
https://docs.mermaidchart.com/blog/posts/7-er-diagram-exampl...
---
title: Order example
---
erDiagram
CUSTOMER ||--o{ ORDER : placesThere 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
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.
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).Its feature-rich, albeit focused on Postgres. And it's ability to compare database schemas makes updating and applying diffs much easier.
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)
I used to query databases and create diagrams from the metadata, but text to diagram just makes little sense to me.
https://mermaid.js.org/syntax/entityRelationshipDiagram.html
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.
SSMS suffers greatly from not having a Jupyter Notebook-style mode; whereas SSMS' cousin in Azure Data Studio does feature it, it's still thoroughly compromised in other ways to make it useless, unfortunately.
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/
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.
BTW, one that did the same for Terraform would make my life so much easier…
The issue I had with them is that they were just plain confusing and "noisy". After reflecting on it a bit, this made sense. Diagrams are only ever easy to follow if they have a clear purpose, but with minimal to no human semantic context, these auto generated diagrams could never be that way. They were just aimless scattershots of boxes with pretty icons on them.
Maybe it was just me not being used to them enough, and I could have grown to appreciate them and utilize them well if I bothered for long enough. But if I think about what I'd want from a diagram, it would be things like how data flows through an infrastructure, which Terraform cannot hope to have an exact idea about. And this only gets worse when you upload custom code, such as by using lambdas, containers, ec2 instances, what have you.
I've used this a bunch early in projects where the team needs to agree on DB structure:
1. whip something up as a discussion piece 2. usually a quick meeting to iterate on it, spot problems, correct. 3. you're close enough to build the DB bits, ship it. :)
vseplet•15h ago
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.
dcreater•12h ago