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.
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
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)
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.
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/
vseplet•8h 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•6h ago